Support for HTML5 and SVG in Web Publishing Tool

[smmarlow]

The web format wars are over, and the plug-ins have lost.  Microsoft has relented and will support HTML5 and SVG in IE9, and has admitted that Silverlight's role will change to that of a Windows phone development platform.  Silverlight support on iPhone/iPad/Andoid/Chrome OS will likely never be fully formed, and will wither on the vine. 

New javascript/ecmascript engines that are much faster, and make use of multicore environments have arrived and work well.  The addiition of WebSockets means your browser can now open a tcp/ip socket.  I have done this, as I am sure others have, as well.  Drop an old-fashioned tcp/ip listener into your diagram, return the WebSocket handshake, and presto: you can now stream data directly to/from your browser.  WebSockets provides an "onmessage" event handler function which you can define.  Combine this with the SVG DOM, and you can transform SVG elements until your heart is content.  Two-way streaming of data between your browser and plain-old tcp/ip?  Goodbye web services, we knew you well. Good riddance, plugins.

I have built my own SVG UI objects using Inkscape (free), and wrote a script (notepad/Inkscape script editor, also free) to handle WebSockets communication without a gateway.  I have a simple LV class built on the TCP/IP functions that will stream data to/from a browser which is pointing to an SVG "webpanel" that I also built using Inkscape.  So far I have a simple waveform graph, buttons, LED's, progress bars, etc.  I have tested my Inkscape webpanels in Firefox 4.0 Beta and Google Chrome 9 and it works like a champ, and is very fast.  The old-fashioned LV webserver will serve up SVG files with the addition of a mime type. 

An alternative to SVG is the HTML5 <canvas> tag, which allows the rendering of graphics drawn using java/ecma script.  There is a free-for-personal-use script library called RGraph Library that you can download with lots of example code.  Here is RGraph/LabVIEW in action in Chrome 9:

So what is my idea?  

0. Ditch Silverlight.

1. Convert all of the nice-looking UI panel objects in the Web UI Builder from Microsoft XAML to SVG and distribute them with the  LabVIEW professional development license.  I am programmer first, and I admit my web panel objects don't look too good.

2. Design a script library for handling WebSockets communcation (or add native support for WebSockets to the Shared Variable Engine) and manipulating/updating the SVG UI objects from streamed WebSockets data.  Make this library open source.

3. Create a standard open protocol for streaming LabVIEW data that sits on top of WebSockets and is free and open.

4. Publish documentation for the SVG UI elements so users and thrid parties can create new UI objects.  Make use of the creativity of the community at large!

5. Modernize the Web Publishing Tool so that it will optionally output an HTML5 and/or SVG document that accepts streaming I/O from WebSockets.  The user could choose from compatible SVG elements to use in place of front panel elements on the VI being published.

6. Create a Web UI SVG element exchange for registered NI users to upload/download elements for free.

7.  Work toward the long term goal of adding SVG Import/Export to the control editor (with better editing tools), or make the CTL format of custom controls SVG/XML.

[jlokanis]

I have been saying all along that Silverlight was the wrong platform for this.  We want to run our web interfaces from tablets, not Windows OS.  If it does not run on the iOS and Android, there is little point in it.  Stick with standards.  HTML5 is the best option.

[PhillipBrooks]

After watching the on-line Web-Based User Interfaces for Remote Monitoring and Control presentation today, I kudo this idea!

[X.]

I don't understand half 90% of what smmarlow wrote, but my first attempts at using LabVIEW WebUI have left me quite skeptical (even leaving the benefit of the doubt to NI developers considering that this is an early version) and unwilling to spend $1.5K to go back to LV 3 in terms of capabilities. The fact that Silverlight is supported on Macs and will be on Linux is positive, but now that smmarlow brought up the other smaller form factor platforms like tablets and such, I see the risk of depending on a Microsoft product... It trust NI to go where the money is. So if Android-based platforms are bound to dominate the market and if that means using web standards, I bet they will. But of course what about all that initial investment? NI has grown big, so they may react as a large inflexible company (think MS), i.e. slowly. The debate will be interesting to watch. I can't contribute intelligently to it, I am afraid!

[JohnBergmans]

Hi mmarlow.

Great minds think alike!  I thought you and others reading this thread might also be interested to hear about "LabSockets", my prototype WebSocket-based solution to extending LabVIEW to a browser.

A few features of note about LabSockets:

• It automatically re-creates the LabVIEW GUI in the browser by doing a screenscrape of the GUI, generating the equivalent Javascript and inserting that JS into a web page. 
• The system uses the Kaazing WebSocket Gateway which features WebSocket emulation capability for many browsers without native WebSocket support - including the Safari browser in early iPads, IE 6&7, etc.
• LabSocket uses a message broker on a cloud server, so developers don't need to worry about setting up their own WebSocket system. (An intranet configuration is also possible but I thought it would be easier to start with a cloud service).

The system is not quite ready for production use, but if anyone wants to try it, shoot me an e-mail and I'll send

you the neccessary VIs.

BTW - I've been communicating with NI (including Mike Neal and Jeff Meisel) for a few months about the LabSocket system, but haven't received much serious interest from them.  I think NI has probably invested so heavily in developing the  Web UI Builder system (which is a pretty impressive technical accomplishment), that they're not quite ready to switch over to a WebSocket solution.  Third-party systems like ours will probably have to suffice for the foreseeable future.

Regards,

John Bergmans

Bergmans Mechatronics LLC

jbergmans@bergmans.com 

Slides: http://www.slideshare.net/JohnBergmans/extending-lab-view-to-the-web-using-labsockets

Video: http://screencast.com/t/eKuQ02PAdo

[GregR]

There are many factors that went into the decision to develop the Web UI Builder in Silverlight. Many of those related to finding the best technology for developing a web-based development environment. Silverlight gave the best solution both for its ability to produce a rich editor experience and for providing a reasonable development experience for us. With C#/Silverlight we get a type-safe language capable of handling the code we require and an ecosystem capable of dynamically integrating code from third parties.

Having made that decision, we also got a natural first choice for a deployment platform. The EAP was identified in an earlier post as LabVIEW 3. In fact that was a target for functionality of this release. It is far from the end though, both in terms of language and targeting. We see the trends and understand the allure of other deployment strategies. HTML5’s strength should be reaching the broadest range of devices. Silverlight’s strength is supporting a richer experience including third-party controls and more substantial client side computation (and our early access release barely scratches the surface of this potential).

Just like a vote for FPGA is not necessarily a vote against RT, a vote for HTML5 does not have to be a vote against Silverlight.

[X.]

I think one of the nice things of LVWUI is indeed the development part. For instance, so far I have tested it mainly to implement some simple data representation/processing based on data pasted by the user as an ASCII string (I would have liked to be able to read/write files on the host computer, but that's not possible - yet). In this application, there is not need to listen to a web server and get data from a distant instrument or VI. It does not appear that this is what John or SM are talking about, but that's definitely what I am interested in. Since I have no clue about Java or Javascript, I have no idea whether that could easily be done in either language (or any other web language for that matter). However, it is relatively straightforward to do in LVWUI coming from LV.

Again, I understand that as a first version, it cannot implement every bells and whistles of LV 2010.

X.

[CrystalTech]

Kudos!... Welcome to the second decade of the 21st century!

[vitoi]

I know what I want and that is the ability to use a standard web browser to access a LabVIEW application, without anything else on the Client side. This way any Client wth a web browser (inlcuding my iPhone and iPad) can access my labVIEW code from anywhere. Wouldn't that be neat!

I know LabVIEW Remote Front Panels gives you this capability and has since at least 2006, but it requires the LabVIEW run time engine on the Client. [having a real hard time doing that on my iPhone 🙂 ].

So I've voted for this since it seems to be heading in the right direction.

NI, imagine the user community's delight to the ability to interact with a LabVIEW front panel from anywhere, with little effort from the LabVIEW developer. This feature would be the best thing since sliced bread (in LabVIEW's case the Event structure, which is the last time LabVIEW got anything significant added to it).

[_Chris]

LabVIEW should be the editor for the UI using SVG + JS.

Currently the main limitation of websocket (draft 76) is that binary format is not supported, so you have to re-encode raw data before sending them.

[smmarlow]

@ _Chris

Yeah, the current websockets protocol does only support text.  But most floating-point data can be rendered viewable with eight characters per datapoint, plus a delimiter, so it's not a big problem to just send delimited text.   If you're talking integer data, you do take a hit with text vs. binary, but at modern broadband speeds most situations are OK.  There's always byte-stuff encoding with a performance hit.  I'm keeping my fingers crossed for a binary version of the protocol.