Jump to content

LV Class Icon Recomendations from NI (Draft 1)

Aristos Queue

Recommended Posts

Aristos Queue Contributor

Aristos Queue

Posted
Posted

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.

Link to comment
Jim Kring Rookie

Jim Kring

Posted
Posted

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

Great glyphs!

Woohoo! I'm famous :thumbup:

Link to comment
Tomi Maila Newbie

Tomi Maila

Posted
Posted

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

Link to comment
PJM_labview Newbie

PJM_labview

Posted
Posted

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

Source image used:

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

PJM

Link to comment
Tomi Maila Newbie

Tomi Maila

Posted
Posted

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

Link to comment
robijn Newbie

robijn

Posted
Posted

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

Link to comment
Aristos Queue Contributor

Aristos Queue

Posted
  • Author
Posted

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... ;-)

Link to comment
eaolson Newbie

eaolson

Posted
Posted

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

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

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?

Link to comment
Tomi Maila Newbie

Tomi Maila

Posted
Posted

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

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)

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

Link to comment
Jim Kring Rookie

Jim Kring

Posted
Posted

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.

Link to comment
Aristos Queue Contributor

Aristos Queue

Posted
  • Author
Posted

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

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"?)

Link to comment
Tomi Maila Newbie

Tomi Maila

Posted
Posted

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

Link to comment
Jim Kring Rookie

Jim Kring

Posted
Posted

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.).

Link to comment
  • 3 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
Go to topic listing
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.

  I accept