LV Class Icon Recomendations from NI (Draft 1)

[Aristos Queue]

The iconography staff for LabVIEW has worked out a set of glyphs for describing LabVIEW classes. This is the first public draft. Over time, LV will be using these glyphs in icons it develops for internal features, and we're recommending this common iconography to customers. Your feedback is welcome.

http://jabberwocky.outriangle.org/LVClassG...yphsFromNI.html

PS: You'll note that the feedback of LAVA was taken in the case of "abstract class". No, I didn't include the blender icon. ;-)

I did get permission from Jim Kring to use his icon.

[Jim Kring]

QUOTE(Aristos Queue @ Mar 24 2007, 12:20 PM)

The iconography staff for LabVIEW has worked out a set of glyphs for describing LabVIEW classes. This is the first public draft. Over time, LV will be using these glyphs in icons it develops for internal features, and we're recommending this common iconography to customers. Your feedback is welcome.

http://jabberwocky.outriangle.org/LVClassG...yphsFromNI.html

PS: You'll note that the feedback of LAVA was taken in the case of "abstract class". No, I didn't include the blender icon. ;-)

I did get permission from Jim Kring to use his icon.

Great glyphs!

Woohoo! I'm famous :thumbup:

[Yair]

QUOTE(Jim Kring @ Mar 24 2007, 11:12 PM)

Woohoo! I'm famous :thumbup:

Aren't you the guy who made http://www.imdb.com/title/tt0813715/' target="_blank">Heroes? :laugh:

Very nice, Stephen.

[Aristos Queue]

QUOTE(yen @ Mar 24 2007, 04:57 PM)

Very nice, Stephen.

Thanks, but it is mostly not my artwork. I used to draw clipart for a job. Now I'm just a consumer of it. ;-)

Save your thanks for people like NI's Laura Hayden.

[Jim Kring]

QUOTE(yen @ Mar 24 2007, 02:57 PM)

Aren't you the guy who made http://www.imdb.com/title/tt0813715/' target="_blank">Heroes? :laugh:

I guess all of the Krings are becoming famous, now

[crelf]

QUOTE(Aristos Queue @ Mar 25 2007, 05:20 AM)

Your feedback is welcome.

All looks good to me :thumbup:

[Tomi Maila]

Hi,

I'm on short vacation so I don't have much time to answer. Looks good Stpehen! A few comments:

Initialize & Start are not similar actions. I think initialize should have a different icon. For example you can initialize your robot object first (at this pahse it's prepared to work properly) and start your robot later later.

p.s. Why some of the icons have a blue background and the others do not?

Tomi

[Yair]

QUOTE(Jim Kring @ Mar 25 2007, 02:11 AM)

I guess all of the Krings are becoming famous, now

How about your other siblings, Kim and Dim?

[PJM_labview]

I did some cleanup of Jim Glyph so the edges are smoother.

• Before: http://forums.lavag.org/index.php?act=attach&type=post&id=5294
  
• After: http://forums.lavag.org/index.php?act=attach&type=post&id=5297
  
• After with transparency: http://forums.lavag.org/index.php?act=attach&type=post&id=5295
  

Source image used:

http://forums.lavag.org/index.php?act=attach&type=post&id=5296

PJM

[Aristos Queue]

QUOTE(Tomi Maila @ Mar 25 2007, 03:46 AM)

p.s. Why some of the icons have a blue background and the others do not?

I don't see any that have a blue background. All should have a transparent or white background. Which browser are you using?

[Tomi Maila]

QUOTE(Aristos Queue @ Mar 26 2007, 01:30 AM)

I don't see any that have a blue background. All should have a transparent or white background. Which browser are you using?

It was a internet explorer in a hotel in Copenhagen. I guess the version was 6.x.

I'm back from my weekend trip so I can take a deeper look in the glyphs.

First I think it's an excellent idea to use glyphs to decorate icons. However current icons are rather small to hold up many glyphs and I suggest this limitation to be removed in future version of LabVIEW.

Second I'm not sure the LabVIEW object icon is good any more now that any object glyph is introduced. There is a risk of misinterpreting the one for the other.

About write and read glyphs. I don't think they actually describe the the function of setting and getting data. Write and read may be the words used in English language but some other languages may have other words for this kind of actions. So using glyphs that describe English words write and read and not the action of setting and getting data is I think a bad idea. I know you have been using these gylphs in icons already so it may be hard to discard them now. However, for example for "Read property" I would use property glyph together with an arrow towards right originating from the prorepty glyph.

About the polymorphic glyph. I don't really understand what is the intended use of this glyph. Could you AQ clarify your intentions. What ever the use is, I don't think the quesitomark should be there as polymorphism is not related to any "questions". Also the question mark is used as a glyph for warning so I think other uses should be avoided.

About the recursion glyph. It's not intuitive to me. There are many kinds of recursion and I think the kind of recursion you are meaning here is a recursive VI. I would use a VI or "method" glyph together with an arror starting from right side of the VI glyph, going around the VI glyph somehow and ending to the left side of the VI glyph.

For public methods, I don't think there is a need for glyph. I think public should be the default. Also a green key is still a key and the only intuitive interpretation is some kind of locking and not being open.

The Initialize and start are different behaviours as I said in my previous post. They should have different glyphs. Starting means starting an action that goes on independently. Initializing doesn't have this dimension of independent action. Think of a VCR. When you power it on, you initialize it. When you press play, you start it.

I think initialize and create should have similar but not same glyphs. I propose a glyph used for initialize is a star symbol without the diagonal elements. I mean a cross '+' with a 3x3 pixel hole in the center.

For errors I would use the same symbol that appears on firefox addressbar when you go to a webpage that doesn't exist.

I'm not sure if there is a need for "user defined" glyph and least not in professional use.

I don't think user defined errors or other classes in class hierarchy should be separate from NI class hierarchy. Class hierarchy should always represent what objects really are. If I write my own network driver, the error it should throw should be a subclass of network error and not subclass of user defined error! So please consider removing the "starting points for customization" from the class hierarchy. These kind of classes do not belong to the class hierarchy!!! They are misusage of OOP and this kind of philosophy may cause troubles to serious developers such as OpenG developers.

About the example hierarchy, network error and device error are both I/O errors and there should be a common superclass.

Then there are some essentianl glyphs missing:

- close (X symbol)

- cleanup / destroy (a different kind of X symbol)

- stop (square)

- message (envelope)

- by-reference (when your object refers to some real-world device for example, the same glyph used in property nodes)

- send (envelope with some "speed lines" to the left or alternatively symbol similar to forward symbol in thunderbird)

- reveice (mailbox)

- open (similar to open symbol in MS word)

- save to disk (similar to save symbol in MS word)

- XML (<XML>)

- clone object (when wire copy is not enough, ???)

- advanced feature (I've no idea)

- fail (red cross)

- ok, not failed (green check-mark similar to the check-mark in system checkbox in Windows XP)

- break, interrupt (a hexagon similar to stop sign)

- wait (time glass)

- timeout (time glass with error glyph)

- lock by-reference object (a closed lock symbol)

- release by-reference object (an open lock symbol)

Regards,

Tomi

[robijn]

Hi,

Looks very promising.

Remember that some people cannot see colour and cannot differentiate between red and green. It's best not to rely on the colours to be seen.

Polymorphic idea: A shape a bit like a jigsaw puzzle piece with different contours on each side: flat, circular, sawtooth...

Type/Class: A circle with a big dot in the center.

Attribute(s): A label connected to a type symbol.

Joris

[Aristos Queue]

QUOTE(Tomi Maila @ Mar 26 2007, 04:54 AM)

If I write my own network driver, the error it should throw should be a subclass of network error and not subclass of user defined error!

You're half right.

You're wrong in saying we don't need it. There's going to be lots of cases of needing this.

You're right in saying that you should inherit from network error.

The resolution of these: the class "network error" should inherit from user-defined error.

There's going to be plenty of places where the G code needs to cross out of LV internals and into LV externals. All the driver groups etc are externals.

As for the missing glyphs -- these are the LV class glyphs only. Not the entire iconography of LV. You mentioned XML. Why not TCP/IP? Or the glyph for file path?

The iconography for the rest of LV is available on the website. This is the LV class additions/standardizations only. And there's no glyph for references included. Guess why... ;-)

[eaolson]

I hesitate to jump into this thread, but I will anyway.

QUOTE(Aristos Queue @ Mar 26 2007, 05:21 PM)

You're wrong in saying we don't need it. There's going to be lots of cases of needing this.

You're right in saying that you should inherit from network error.

Why wouldn't the whole Error class tree start at General Error? It seems that that would have some sort of basic error functionality that was extended in the subclasses. What's the advantage to making them siblings? (In Java, for example, everything inherits from a general Error class.)

I can sort of see the need for multiple classes of errors as prototyped in this example. But how would a VI that was expecting, say, a Network Error behave if it was wired a Device Error instead? Those are sibling classes. Would there be an implicit typecast up to Abstract Error and then a typecast down to Network Error? (My experience with LVOOP is a bit sketchy at this point; apologies if that's a blindingly obvious question.)

The whole error IO paradigm as it stands in LabVIEW only makes sense if a VI can accept an error and pass it down the line as far as it needs to go, possibly into and out of VIs that are not aware of that particular error customization. Is it envisioned that this will change in the future, or will error clusters be replaced with Abstract Errors?

I kind of see Tomi's point. The only reason to have a specified User Defined Error is if the other error types are not user-definable. Does this mean I won't be able to sub-class off of DAQ Error?

[Tomi Maila]

QUOTE(Aristos Queue @ Mar 27 2007, 01:21 AM)

You're wrong in saying we don't need it. There's going to be lots of cases of needing this.

Aristos, could you share some of these use cases=

QUOTE(Aristos Queue @ Mar 27 2007, 01:21 AM)

The resolution of these: the class "network error" should inherit from user-defined error.

So you are saying that the class hierarchy will be divided to segments that user cannot extend but NI can, and to segments that user can extend. What is the design decision behind this concept?

QUOTE(Aristos Queue @ Mar 27 2007, 01:21 AM)

As for the missing glyphs -- these are the

LV

class glyphs only. Not the entire iconography of

LV

. You mentioned XML. Why not TCP/IP? Or the glyph for file path?

I was just listing the core concepts I use with LV classes. Well, I'm not using "break/interrupt" nor "advanced" currently.

QUOTE(Aristos Queue @ Mar 27 2007, 01:21 AM)

And there's no glyph for references included. Guess why... ;-)

I think there should be. Consider someone writing a device driver for a device. Very propably a referece to the physical device will be used as private data. So actually the wire acts like a reference and not like a value. How does user know if a wire acts like a by-reference wire or like a by-value wire. I was suggesting that a glyph could be used to distinguish these two use cases. Well there is always the case of mixed wires as well with both references and values, but I've no solution for those wires.

Tomi

[Jim Kring]

QUOTE(Aristos Queue @ Mar 26 2007, 03:21 PM)

And there's no glyph for references included. Guess why... ;-)

My guesses are that its either a confidential feature that you don't want to disclose or its because NI doesn't think that we need by reference objects -- I hope it's the former.

[Aristos Queue]

QUOTE(Tomi Maila @ Mar 27 2007, 01:50 AM)

So you are saying that the class hierarchy will be divided to segments that user cannot extend but NI can, and to segments that user can extend. What is the design decision behind this concept?

The division would be between sections that NI wouldn't change the interface between versions and sections for which NI might completely blow away the interface. Up to now, the general principle of vi.lib has been "if it is in the palettes, then it needs to have the same functionality version to version or provide mutation code so that the user's diagram gets modified to have the same functionality (to the degree it is possible to do so). If a VI is not in the palettes, you can rewrite it as needed." If NI starts deploying LV classes that are part of standard libraries, there are going to be interfaces that must be stable version to version and there are interfaces that might be completely blown away.

In the prototype of the error class hierarchy that I posted (different LAVA thread), there are two classes that handle the <err> and <append> tags respectively. Those are internal components, and in my vision, if you inherited from them, you shouldn't expect that the API stays consistent version to version of LV. Anything with the user-def symbol is a promise from NI to remain stable and functional with the same API.

QUOTE(Jim Kring @ Mar 27 2007, 02:23 AM)

My guesses are that its either a confidential feature that you don't want to disclose or its because NI doesn't think that we need by reference objects -- I hope it's the former.

Almost... it's because these are the glyphs that LV classes add to LV... and we haven't added references. Whether or not this may happen in the future is an open question.

QUOTE(Tomi Maila @ Mar 27 2007, 01:50 AM)

I think there should be [a reference glyph]. Consider someone writing a device driver for a device. Very propably a referece to the physical device will be used as private data. So actually the wire acts like a reference and not like a value...

The glyph for "refnum" is the document with the folded corner. I don't know how this came to be the glyph for it, but it's used *everywhere* in LV, and used fairly consistently. (Yes, it is also used to indicate "file" which makes "file refnum" sort of interesting, IMHO.)

I'd expect that whoever created the reference class would decorate it with the appropriate symbol -- ie, Endevo might have a mark, and dqGOOP might have a different mark. These would only be appropriate if there were a functional difference between reference classes created by the different toolkits. If an individual customer creates a reference class of his/her own, the mark would want to be different again since the class wouldn't be usable in conjunction with the hierarchies generated by the aforementioned tools. If LV ever creates a native reference type, then there'd be a glyph from us to represent LV reference, but as nonesuch exists, it didn't make sense to try to glyph it now (is "glyph" a verb? Hm... perhaps "iconify"? "draw"?)

[Tomi Maila]

QUOTE(Aristos Queue @ Mar 27 2007, 07:11 PM)

The division would be between sections that NI wouldn't change the interface between versions and sections for which NI might completely blow away the interface.

I see, so you kind of have classes that should be of some sort of private scope. Wouldn't it be better then to use a special "private class" glyph for these private items. I think it would be more intuitive than using a glyph for "user customizable" classes. Anybody second me on this?

Tomi

[Jim Kring]

QUOTE(Aristos Queue @ Mar 27 2007, 09:11 AM)

The glyph for "refnum" is the document with the folded corner. I don't know how this came to be the glyph for it, but it's used *everywhere* in LV, and used fairly consistently. (Yes, it is also used to indicate "file" which makes "file refnum" sort of interesting, IMHO.)

I believe that it is because the datalog file refnum is used as the type for GOOP objects (and the datalog file refnum shell has the folded corner, as you mentioned). This choice (to use the datalog file refnum) was made, because (1) the datalog refnum type can be defined by the data type placed inside of it (e.g., making it impossible to wire a Semaphore refnum to a Rendezvous refnum, both of which use datalog file refnums as their reference data type) and (2) because the datalog file refnum's data is a U32 which makes it great for passing any object reference (VI, Queue, repository element index, etc.).

[crelf]

QUOTE(Jim Kring @ Mar 25 2007, 10:11 AM)

I guess all of the Krings are becoming famous, now

That's awsome - Tim Kring wrote a script for Knight Rider! (don't Hassle the Hoff...)

[Yair]

QUOTE(crelf @ Jul 26 2007, 10:05 PM)

Tim Kring wrote a script for http://www.imdb.com/title/tt0084218/' target="_blank">Knight Rider!

I guess I managed to edit that one out of my consciousness.

[crelf]

QUOTE(yen @ Jul 27 2007, 05:30 AM)

I guess I managed to edit that one out of my consciousness.

Awww c'mon! Who could forget http://homepages.paradise.net.nz/~acorn/kr/audio/themes/Season1.mp3' target="_blank">this?

Hey cool! The SnapShots preview has a little media player in it if you link to media files :thumbup: