Web UI Builder - feedback wanted

[Mr Mike]

I think the stuff you've put together looks pretty slick. Since I'm (nominally) on the Web UI Builder team, I'd like to get an idea of what else you don't like about Web UI Builder.

So far, I've got this:

1. It's only on Windows and Mac.
2. It requires a plugin.
3. Price (note: the price is for building apps for deploying; it's free for developing). Do you think that you should get free / discounted access to build/deploy apps after buying some other product / combination of products? (Note: I have absolutely nothing to do with the business side of things, so I don't have any input on pricing, bundles, etc. I can represent your feelings if I'm around when the discussion comes up)

What else?

Edited April 24, 2011 by crelf
Thread split from http://lavag.org/topic/13777-hello-websocket-and-svg-goodbye-web-ui-builder/

[John Lokanis]

In my opinion, the only thing wring with the Web UI Builder is the use of proprietary Microsoft Silverlight. If you were to output a site that would run using only HTML5, then it would work across all devices.

The cost is also a bit of a barrier, but if I needed this for my project, I think I could get the company to pay. Not sure I like the expiring licence model, however. I think you should treat this more like the app builder and charge for the tool, but allow all output to be free to use and distribute.

[mje]

In my opinion, the only thing wring with the Web UI Builder is the use of proprietary Microsoft Silverlight. If you were to output a site that would run using only HTML5, then it would work across all devices.

Agreed. If I'm going to make a web interface for a device, I want it to be open to not only windows desktops, but other operating systems, as well as IOS/Android/Whatever devices. Why would I develop a platform locked web interface when I can already develop a more open stand-alone application?

The Web UI Builder looks slick as can be, and I really think it's a push in the right direction (thin clients), but I don't think using silverlight was the way to go given how html technologies have evolved and non-desktop platforms are becoming more predominant every day.

[Richard_Jennings]

Agreed. If I'm going to make a web interface for a device, I want it to be open to not only windows desktops, but other operating systems, as well as IOS/Android/Whatever devices. Why would I develop a platform locked web interface when I can already develop a more open stand-alone application?

The Web UI Builder looks slick as can be, and I really think it's a push in the right direction (thin clients), but I don't think using silverlight was the way to go given how html technologies have evolved and non-desktop platforms are becoming more predominant every day.

I agree 100%

[ShaunR]

Agreed. If I'm going to make a web interface for a device, I want it to be open to not only windows desktops, but other operating systems, as well as IOS/Android/Whatever devices. Why would I develop a platform locked web interface when I can already develop a more open stand-alone application?

The Web UI Builder looks slick as can be, and I really think it's a push in the right direction (thin clients), but I don't think using silverlight was the way to go given how html technologies have evolved and non-desktop platforms are becoming more predominant every day.

Yup.

I think also that the explosion of Ajax enabling "desktop style" dynamic web pages that run in the browsers native engines has put the nail in the coffin of external run-times like Silverlight. Things like flash Java etc are really now only used as presentation tools rather than dynamic page content. Try and find a site now that doesn't have jquery for example. Sure it's not graphical. But JavaScript developers are the new C developers;10-a-penny and cheap.There are many data streaming sites now using JS push servers for things like real-time stock quotes.

In terms of graphical presentation (like graphs etc). I'm looking at Google maps. Not so much in using it as-is. But the technology. Javascript based with bi-directional feedback allowing zooming, panning, and overlays. All that a web-page requires is the DIV tag and a link to the javascript and the browser does the rest.

Now. If there were a tool (like the web-builder) that created javascript (like the embedded toolkits create c). I would be getting very excited. I could then use it to create front ends for my Labview websockets. Have to be free of course.

Edited April 22, 2011 by ShaunR

[smarlow]

Mr. Mike,

I developed the HTML5/Websocket script mainly just to see if I could do it. I had been reading about the technology, and became motivated by the $1500/yr deployment license fee charged by NI for Web UI Builder. NI's RT customers can easily drop $6K-$10K on a cRIO with some horsepower and fancy modules. Another 10K for the LabVIEW Developer's Suite with RT and FPGA and we're talking really serious money, much more if you're building multi-core RT PXI systems. Do you really expect these customers to pay $1500/yr extra for the interface technology that should already be included in the stuff they just bought? That takes some chutzpah!

NI can be forgiven for choosing Silverlight as a platform, since there was a lot of noise about it and it seemed like many platforms were open to supporting it. But it seems like you guys went to a lot of trouble to recreate a portion of the LV development enviroment in Silverlight. Why? Even though it's pretty cool, I really don't need that on the client side. Who wants to write two programs instead of one? And if I do want to program a whole bunch of stuff on the client side and be locked into a Windows (or Mac) machine with a plugin, why not just use LabVIEW?

The stuff I built and posted here (and on the LV idea exchange) was created using Inkscape and Wordpad. I did it to see if I could build a halfway decent interface for free using the new gadgetry in Chrome. While working on the project, I also ran across the RGraph library and decided to test it. Granted the look of my stuff is not that great, and the script is clunky in places. But the idea works, which is all I wanted to prove.

I am a loyal user of NI's products, and swear by them to my clients, but NI needs to play catch-up, and do it fast. One thing they can do right away is at least include a Web UI deployment license to owners of LabVIEW RT and purchasers of your RT hardware. Asking owners of these expensive products to pony up more cash to make them shine is a real test of their loyalty. The next thing you need to do is have a standards-based deployment option so the interface will run on any platform.

What I would like to see is a move by NI to add SVG import/export support in LabVIEW itself, and a modern HTML5 version of the Web Publishing Tool. This new version of a familiar tool would publish the front panel of any VI as a collection of standards-based objects that will run in any modern browser without the need of a plugin, or any additional programming. Let's face it, the control editor belongs in the 20th century. Adding the SVG support would allow third parties to develop controls and indicators using Illustrator, Inkscape, CorelDraw, and other commercial vector drawing programs.

Here's more info on my original post at NI's Idea Exchange

I think the stuff you've put together looks pretty slick. Since I'm (nominally) on the Web UI Builder team, I'd like to get an idea of what else you don't like about Web UI Builder.

So far, I've got this:

1. It's only on Windows and Mac.
2. It requires a plugin.
3. Price (note: the price is for building apps for deploying; it's free for developing). Do you think that you should get free / discounted access to build/deploy apps after buying some other product / combination of products? (Note: I have absolutely nothing to do with the business side of things, so I don't have any input on pricing, bundles, etc. I can represent your feelings if I'm around when the discussion comes up)

What else?

[Mr Mike]

Mr. Mike,

I developed the HTML5/Websocket script mainly just to see if I could do it. I had been reading about the technology, and became motivated by the $1500/yr deployment license fee charged by NI for Web UI Builder. NI's RT customers can easily drop $6K-$10K on a cRIO with some horsepower and fancy modules. Another 10K for the LabVIEW Developer's Suite with RT and FPGA and we're talking really serious money, much more if you're building multi-core RT PXI systems. Do you really expect these customers to pay $1500/yr extra for the interface technology that should already be included in the stuff they just bought? That takes some chutzpah!

I'm not involved in any of the business decisions (such as pricing, bundling, etc). I was just curious about your reaction to LabVIEW Web UI Builder in general. I asked to have this thread split out of yours since I had unintentionally hijacked your thread.

The stuff I built and posted here (and on the LV idea exchange) was created using Inkscape and Wordpad. I did it to see if I could build a halfway decent interface for free using the new gadgetry in Chrome. While working on the project, I also ran across the RGraph library and decided to test it. Granted the look of my stuff is not that great, and the script is clunky in places. But the idea works, which is all I wanted to prove.

And you did a damned good job of proving it.

NI can be forgiven for choosing Silverlight as a platform, since there was a lot of noise about it and it seemed like many platforms were open to supporting it. But it seems like you guys went to a lot of trouble to recreate a portion of the LV development enviroment in Silverlight. Why? Even though it's pretty cool, I really don't need that on the client side. Who wants to write two programs instead of one? And if I do want to program a whole bunch of stuff on the client side and be locked into a Windows (or Mac) machine with a plugin, why not just use LabVIEW?

I am a loyal user of NI's products, and swear by them to my clients, but NI needs to play catch-up, and do it fast. One thing they can do right away is at least include a Web UI deployment license to owners of LabVIEW RT and purchasers of your RT hardware. Asking owners of these expensive products to pony up more cash to make them shine is a real test of their loyalty. The next thing you need to do is have a standards-based deployment option so the interface will run on any platform.

Again, I don't have much say in the business side. I agree that NI ought to be further ahead in terms of internet technologies. However, one of the major hangups (in my opinion) is that you've got to use a graphical programming language to write out a text markup (HTML) which is then rendered as a graphical system (a web page). We want to cut out the text part (not because we hate text-based languages: if we did, we'd rewrite LabVIEW in LabVIEW ) because that transition (text to graphical) limits by nature and by design how your data is represented and displayed. Your text is put in a box that you can control a lot of the appearance of, but very little of the behavior of. As a front-end display, that actually fits pretty well. As a front-end control panel it would hold up for basic usage, but I think it wouldn't work for very long without an incredible investment in the controls and protocols.

I doubt we could produce an interactive front end in javascript / html[5] that was half as responsive as a plugin-type system (.NET). Of course if it's just a basic front-end that doesn't need a lot of interaction, that's a great option.

What I would like to see is a move by NI to add SVG import/export support in LabVIEW itself, and a modern HTML5 version of the Web Publishing Tool. This new version of a familiar tool would publish the front panel of any VI as a collection of standards-based objects that will run in any modern browser without the need of a plugin, or any additional programming. Let's face it, the control editor belongs in the 20th century. Adding the SVG support would allow third parties to develop controls and indicators using Illustrator, Inkscape, CorelDraw, and other commercial vector drawing programs.

I agree we need SVG support. We have an internal tool which would vastly benefit from SVG support. It kinda makes me cry that there's no (easy) way to display an SVG file in LabVIEW. Though importing SVG for a control? I think there's more work there than we could tackle in one or two releases. Unfortunately, I don't think that's on the decision maker's radar. Right now, it's speed and stability.

I don't use the Web Publishing Tool, so I can't really comment on that.

I do want to let you know that I get what you're saying. I didn't reply to a lot of it because I don't have time to address every issue (or maybe it's because of super-secret NI plans, or I'm hungry and want to go home for dinner). Thank you for your feedback. I'm not about to go running to the business side saying we need to do these things, but I will (continue to) represent these views when the time arises.

[smarlow]

Thanks for all of your feedback, too. I'm glad someone at NI is listening.