|
View:
New views
4 Messages
—
Rating Filter:
Alert me
|
|
|
Icon set design methodology.As promised I have been looking at completing and refactoring the icon
set using a rational design methodology. Currently we have a good but incomplete set that is a bit drab and inconstant in it's use of color and sub-icon motifs. I am devising a more systematic way of designing icons, one that can be documented and allows for systematic motif reuse. (OOD) For example: If we take this distinct group of icons, http://www.k-3d.org/wiki/Painter_Plugins We can fit them all into this ontology below. Each tag becomes a motif that can be assembled with others to create a complete icon that can be read in a logical way. See attached for a couple of examples. N.B. these are a WIP and I am interested in feed back on the method, rather than the style of the examples. Noted the motif labels with the *, why do these exist for RenderMan, but not for GL? painter plugin types Script OpenGL RenderMan VirtualOpenGL Script MultiPainter Edge Numbering Half Face Normal Numbering ColorFace Point Numbering SDSEdge SDSFace SDSPoint Patch BezierTriangle Bilinear Bicubic BlobbyPoint Blobby Cone CubicCurve Cylinder Disk Hyperboloid LinearCurve NURBS Curve Numbering Patch Numbering NormalArray Paraboloid SL Sphere Teapot Torus VaryingData VertexData Particle * Polyhedron * SubdivisionSurface * SDSEdge SDSFace SDSPoint ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: Icon set design methodology.On Mon, Sep 21, 2009 at 6:09 AM, Daniel Scott Matthews
<dsmatthews@...> wrote: > As promised I have been looking at completing and refactoring the icon > set using a rational design methodology. > > Currently we have a good but incomplete set that is a bit drab and > inconstant in it's use of color and sub-icon motifs. > > I am devising a more systematic way of designing icons, one that can > be documented and allows for systematic motif reuse. (OOD) > > For example: > > If we take this distinct group of icons, > http://www.k-3d.org/wiki/Painter_Plugins > > We can fit them all into this ontology below. Each tag becomes a motif > that can be assembled with others to create a complete icon that can > be read in a logical way. See attached for a couple of examples. N.B. > these are a WIP and I am interested in feed back on the method, rather > than the style of the examples. Noted the motif labels with the *, why > do these exist for RenderMan, but not for GL? > > > painter plugin types > > Script > > OpenGL > RenderMan > VirtualOpenGL > > Script > MultiPainter > > Edge > Numbering > Half > Face > Normal > Numbering > ColorFace > Point > Numbering > SDSEdge > SDSFace > SDSPoint > > Patch > BezierTriangle > Bilinear > Bicubic > > BlobbyPoint > Blobby > > Cone > CubicCurve > Cylinder > Disk > Hyperboloid > LinearCurve > NURBS > Curve > Numbering > Patch > Numbering > NormalArray > Paraboloid > SL > Sphere > Teapot > Torus > VaryingData > VertexData > Particle * > Polyhedron * > SubdivisionSurface * > > SDSEdge > SDSFace > SDSPoint > Also, using this as a guide, http://www.k-3d.org/wiki/Plugin_Categories we can generate and use our base icons for each plugin category so that the higher level menu items can have an icon. Searching, sorting and filtering document node lists by these categories in the GUI would also be driven by the same data.. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: Icon set design methodology.Daniel Scott Matthews wrote:
> As promised I have been looking at completing and refactoring the icon > set using a rational design methodology. > > Currently we have a good but incomplete set that is a bit drab and > inconstant in it's use of color and sub-icon motifs. I should mention up-front that everyone I speak to comments on the consistency and professional appearance of the icons, so I'm hoping that this would be a matter of "tweaks" to any current icons, rather than wholesale changes. > I am devising a more systematic way of designing icons, one that can > be documented and allows for systematic motif reuse. (OOD) > > For example: > > If we take this distinct group of icons, > http://www.k-3d.org/wiki/Painter_Plugins > > We can fit them all into this ontology below. Each tag becomes a motif > that can be assembled with others to create a complete icon that can > be read in a logical way. See attached for a couple of examples. N.B. > these are a WIP and I am interested in feed back on the method, rather > than the style of the examples. Noted the motif labels with the *, why > do these exist for RenderMan, but not for GL? > Particle * > Polyhedron * > SubdivisionSurface * We don't have a separate particle painter in OpenGL because - for the time being - it would be redundant ... the points that go into a particle primitive are already rendered by the point painter. There is no polyhedron painter in OpenGL because we have separate painters for edges and faces. Similarly, there are separate point, edge, and face painters for subdivision surfaces. FWIW, ideally users shouldn't be manipulating painters directly at all, and we have an action item to hide them in the Node List Panel, so you might consider a single "generic" painter icon, so you can focus on other issues. Cheers, Tim [tshead.vcf] begin:vcard fn:Timothy Shead n:Shead;Timothy org:www.k-3d.org email;internet:tshead@... title:Founder x-mozilla-html:FALSE version:2.1 end:vcard ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: Icon set design methodology.On Mon, Sep 21, 2009 at 12:37 AM, Daniel Scott Matthews
<dsmatthews@...> wrote: > Also, using this as a guide, > http://www.k-3d.org/wiki/Plugin_Categories we can generate and use our > base icons for each plugin category so that the higher level menu > items can have an icon. > Searching, sorting and filtering document node lists by these > categories in the GUI would also be driven by the same data.. Sounds like a good idea! I think filtering and generally making the node lists more compact should definitely be on the todo list for 0.8. Cheers, -- Bart ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
| Free embeddable forum powered by Nabble | Forum Help |