Shiny Web UIs

...like deciding about arts... it's in the eyes of the beholder...

It's an interesting discussion going on here

@Gordon , it would be interesting to get your input on professional UIs and how we can enhance them in Blynk.
I would also like to point out that Blynk might seem dumb for you, because it controls things remotely, but... it also gives you full freedom and flexibility in incorporating your own code and logic. We considered Firmata at the very early stages of Blynk, but completely refused from it because it didn't suit us.

@LawrenceGrif, sorry to hear about the crashes, I think that they might be caused by iOS 7.x. We already fixed it, and app will be updated this week. Please tell us about your crashes on our forum – we would be happy to investigate and help you.

Thanks.

--
Pavel

Hi Pavel,

Thanks for posting up - sorry to seem a bit negative... I think I'm worried because the protocol seems very specialised, which is great for very simple control of pin states but not so good for more complex stuff.

But hey... most people do just want to turn stuff on and off from their phone (at least at first) so maybe you're actually on the right track.

So how would you actually go about adding your own code and logic at the moment? Which device does it run on?

Also, do you have a way to get the same UI on a web browser? Or do you have to have a phone with the app installed?

It feels to me like at the moment you don't get much from using a phone app rather than a website, but hopefully that'll change when you add things like Bluetooth.

I love the look of the Blynk app - the widgets are beautiful. From my point of view, if the designer and widgets were all a website it would be much more exiting. If I could buy a magic box that I could plug into my network, design UIs on, and then use to communicate with all my devices (maybe over other non-wifi radios) from PC/Mac/iOS/Android without an app it'd be perfect (for me :) ).

@Gordon

Our protocol supports main 6 commands:

digitalRead/Write
analogRead/Write
VirtualRead/Write

"Virtual Pins" were designed specifically for Blynk to allow sending any data (e.g String, ints) to the app and back. This is one of the reasons why we didn't use Firmata.

There are two layers. 1 responsible for connection , 2nd for commands processing.

We build Blynk hardware agnostic and now it supports almost every popular maker's hardware and shields on the market. You can see full list here - and it's constantly updating.

BTW, We have lots of requests from Espruino owners to add it to Blynk. We would love to see Espruino there, we just have no time for it now. May be someone from that this amazing community will initiate it and we will help.

There were a few comments on security. Well, it's hard to implement software security on Arduino. You can achieve it by connecting to the hub, or adding hardware security. More powerful devices will of course have more options. All the other connections (Apps <-> Server) are using mutual SSL. If you connect over USB- we also provide security.

Since our server is open source - you can download it and install locally, even on the Raspberry Pi - this will give you full control of your network of devices.

Regarding flexibility:
Here is an example for Arduino UNO with Ethernet shield. There are just a few lines of code in order to get Blynk running. And they don't interfere with any code you will add on top of that. Of course there are some specifics(e.g. avoid using long delays), but overall it just works.

include <SPI.h>
include <Ethernet.h>
include <BlynkSimpleEthernet.h>

char auth[] = "YourAuthToken"; // Find your Token in the app and paste it here

void setup()
{
  Serial.begin(9600);
  Blynk.begin(auth); // Here your hardware connects to Blynk Server
}

void loop()
{
  Blynk.run(); // Blynk commands processing happens here 
  //Your code goes here
}

// Next command gets value from the Widget in the app
// which is attached and writing to Virtual Pin 1
BLYNK_WRITE(1)
{
incomingValue =  param.asInt(); // This is the value from the Widget
  // You can also use: asStr() and asDouble()
}

We don't plan to have a web interface, because working as a UX designer for last decade in web, mobile, automotive and IoT , I definitely feel a strong trend towards mobile. And this is where we see Blynk.

We hope that Blynk will become your Magic Box in one Box :). As we add more and more widgets you might not need to design your own ones. However, I would really love to hear about your needs. What are those bits of interface you would like to use?

Mobile and Web are not mutually exclusive... The revolution to turn virtually everything - offline applications and fat clients - into Web in only a few years in the outgoing millenium is happening as well. Responsive with RESS is growing to the point that going native is affordable only for very specifc applications applications. All other things use the universal browser platform to show itself.

Agreed, it is way easier to get something installed on a device as 20+ years ago (then it was labptop/desktop)... but a similar thing can be said about the browsers as the universal, compatible platform for applications on ANY device - small smart phone to large smart tv: there was a time the term crossbrowser compatibility was THE elephant, but this elephant is about gone.

I could though see a combination of native app and server who hosts the definitions/configurations. It is still a pain for the native app provider to cover all the devices OS: iOS, Android, Windows, but the applications running within an elevated, dedicated platform, such as Blynk, share the common source from a server. Since connectivity has to be there anyway, I see no issue. To make things perform, the elevated, dedicated platform can implement a caching mechanism that supports reading the app only on update. From such a platform I would also expect to have a application selection mechanism: not all is in one (big scrollable) page, but organized in seperate distinctive, user defined view, easy to navigate through.

In the end, the system is hybrid: the runtime natively implemented, and the admin Web implemented - and of course seamlessly (for the admin part, the embedded browser is used to render what is comming from the admin Web server as Web pages).

While I agree with some of your points, mainly that "it would be great if everything worked on web", but I don't think it will happen this way. It's more of a dream thing than reality. Let me share my thoughts on it.

1. Mobile web usage is eating desktop web usage, it's a fact. Already. Which leads us to a thought: who will be defining the web experience: desktop or mobile. For me, the answer is pretty obvious.

2. Mobile web user experience is very different from desktop. Starting from interactions to performance-related things (switching tabs, reloading). So, taking into account the statement above: mobile will define the web, ux will be different and of course mobile oriented. Not sure will it be browsers, we'll see. I believe that experience matters, but today ordering a taxi in a web browser is absolutely different from taking an Uber in a few touches in the app.

3. Responsiveness, for me personally, is a myth. I even made my own user research (~60 respondents) and it shows that users clearly prefer full-version websites over those adapted for mobile. Why? Mainly because...they can't zoom! I know it's funny but it's a reality. Also, mobile versions obscure website's functionality (e.g "hamburger menus" - no one sees them/don't know what it is). If anyone can show me a really well done really mobile responsive website - please do so(rearranging the blocks doesn't count). The only exceptions are sites designed "mobile-first". BTW, we already see preparation phase for responsive mobile design. Just look at "flat" design, "material design" by google. I think it's a logic evolution for interfaces that should work across platforms, where accent is no longer on assets, but on code which define scaling, padding, coloring, etc.

4. While I'm absolutely not excited about supporting variety of resolutions and platforms, :) it seems that this is the only one path today. Web is not even close to solve it. I hope that mobile will (finally) be able to render vector graphics and since then we will see fully responsive mobile design without worrying about resolutions.

Again, these are my thoughts, and I bet on mobile :) definitely not web.

VirtualRead/Write

Thanks - that's what I'd hoped for. I didn't see that in the protocol docs on GitHub, but maybe I wasn't looking hard enough.

Did you consider pushing your existing protocol over MQTT? I ask because it would make it easy to have one or more local 'hubs', that then pushed data securely to your servers.

I get your points about mobile/web. Bloated, app-like websites that disable scaling frustrate me every day. I still don't believe that websites have to be like that.

Still it's a shame about the lack of Web-based control for me. While more people are using mobile, if I'm at the PC (like now) it'd be nice to be able to just bring up a website to control things, rather than pulling out my phone.

Out of interest, how do you implement all your widgets multi-platform? Do you reimplement everything on each platform, or do you use HTML/SVG and WebViews?

@Gordon

Yes, our documentation should be better and we are working on that. It's all about resources and time :)

However it's explained here: https://github.com/blynkkk/blynk-library­/blob/master/docs/Implementing.md#virtua­l-pin-operations

This document is for those who want to participate in creating support for other hardware.

We also cover it in Blynk Basics doc. It will be soon on the website.

MQTT support is almost ready, but right now we are focused on user's feedback.

I agree that often it's more convenient to use desktop. Since we have all the assets and technology in place - we might build a web interface at some point and it would be pretty easy to do. It's just not the priority for us.

And yes, we have to recreate widgets for both platforms :( This is pain, but at least design assets are reused.

Thanks for the reply... All good to know. It's a shame you have to recreate all the widgets each time though.

Come to think of it, are you supporting Windows Phone as well? ;)

It's all about resources and time :)

Believe me, I know what you mean...

@Blynk, my point was not mobile or desktop - yes, balance has already tipped towards mobile, but how is 'mobile' defined...

My point is native versus Web.

Native means: application platform is the device OS and version and applications are device OS and version specifically written and have to be downloaded and installed.

Web means: application platform is the universal browser and applications are written only once and run in the browser. 'Download' is transparent - dynamically and on demand, and when device storage gets tight, user has not to chose between which apps to keep and which ones to toss.

The comment about Mobile Web sucks on Desktop, is correct when UX design failed and no responsive framework is used. Building a real responsive and RESS - responsive with server side components - framwork and - really real estate oriented - UI versions can be done but turns out expensive and increases development complexity, especially with maximum reuse in mind. For example, each page has a device dependent table of contents / reference list what component and which implementation of this component to include and which ones not to include, and components are different only when real estate matters... said so: widgets with more elements have to be broken down or have to have multipe versions, models' values are populated in increments as user goes from initial/superficial to depth, and controller has to strike a compromise. As imaginable, this get's pretty complex and may not by all what is expected, and becomes also partially meaningless because bandwidth and plans grow (with same user costs). Higher develoment costs - because of elaborate implementations - are justified only when ultimate performance is required.

A mobile first UI approach on top of a framework good framework - that is actually/literally responsive and takes care of the hamburger and steakes - delivers good results. A framework with just CSS does not cut it, nor an application UI that uses only CSS with media query to hide and show things according to available real estate.

The application UI has to be responsive as well and load only the things that actuall - can be shown right away on the device (first fit, fit above the break). A hiding or reflow to endless (vertical) scrollable pages yield not a pleasant UI. On the other hand, for users swtiching between devices with small and large real estate, UI layout and flow have to stay 'structurally familiar', otherwise the user gets lost. In other words, a lot of fine line walking and compromises are required.

Btw, a 12" tablet, is it a mobile or a desk/lap top? And what about all the hybrids with flippable screens? ...with touch, mouse, or both?

After all, it is real estate, that makes the decision... because the human eye sight resolution is a given ...and looses out with age :(

At Google IO this week Polymer web components are now production ready
https://www.polymer-project.org/1.0/
Not SVG sexey but responsive cross browser, with Web notification (Push notifications for the web) helpers. And you can build your own elements.

Looked into Polymer a while ago... and it is the logical continuation of extensible SGML. Since in the end it is HTML and CSS (and JavaScript) that a browser has to understand, getting the right HTML and CSS (and helping Javascript) in will get you to any place. At the time I had to go production, about 2007 and no HTML5 - the available framework and toolkit supporting such things was dojotoolkit.org. jQuery was already around as well but followed quite a different approach...

With dojo - the widgets are dijit widgets - start in the code as plain divs or inputs or... you name it, and have the html extensible property data-dojo-... in them. After loading the page - or with single page applicaitons, afer loading a new 'basic' html piece with 'dojo/dijit ingredients' - a one-time-parse goes through the dom (or dom branch) and 'converts' the dom to what it has to be to show the desired look. (Nice description of the lifecycle of a/any dijit widget.
At the time when dojo came up, crossbrowser compatibility - and other browser deficiencies in regard of dom manuplations, such as memory leaks - was/were still a great deal, and dojo was a greate choice to have that hidden from the application code. Developing a - templated - widget is easy: a mock html fragment is used as string for the template, and where things have to be variable, templating techniques are use to contextualize that and additional attributes called attachepoints can be added to make the dom nodes of interest as easy accessible as properties of a view-model, with all the benefits of synchronization/eventing if so is desired. Since initiation, other techniques have been added, beause templating is not the most fastest, though a very easy to understand and fast to develop.

Polymer goes much further and aliminates a lot of internal plumbing (and restrictions, and also the shadow dom), and it pulls the viewmodel and view tighter together to a seamless single thing: Web component. I'm glad it has just been released as version 1.0. On top of this matured infrastructure it should not be that hard to add designer-looks vs. geek-frugalities. For sure, what ever has been done, is not just smoke and mirrors, but solid OO and M*VC implementations... and it obviusly works across browsers too.

Hi all, just got a prototype of Blynk library.
It runs on Espruino (over USB) & Node.js (TCP and SSL):
https://www.npmjs.com/package/blynk-libr­ary
Could you please take a look? Any help (ideas, code reviews, patches) are welcome.
Please note that I'm not a pr0fessional JS coder :)

Tested it on Espruino Pico

All I've working with thingstudio and they are currently implementing support for HTTP get/post/put which should mean it will talk to Espruino. They have been doing some great work under the hood. I've just created my first SVG widdgets using their template-ing system.
Will give a heads up when it's in state to play with.

@vshymanskyy, I tried to use it.... but run into some challenges:

1. On my Android device, which board do I pick? Espruino is not listed. So I picked 'Generic Board'.
   
2. The (top) module is found and loaded, but modules referenced by the (top) module cannot be resolved... (due to nature of how require() is executed - @Gordon, is that correct?). In addition to this, the module is very fatt for Espruino. With limited resources available, either platform specific JS modules have to be pre-built or a generator / extractor is in place that on require manages to deliver the elements as needed and composed as best suitable.
   
   

@Gordon, is there an option to do an upload to - like - null device so no connected Espruino is required to formally verify code?

I think the correct usage is:

var Blynk = require('http://tiny.cc/blynk-js');
var blynk = new Blynk.Blynk('715f8caae9bf4a91bae319d0376­caa8d', options = {
  certs_path : '../certs/'
});
var v1 = new blynk.VirtualPin(1);
var v9 = new blynk.VirtualPin(9);

v1.on('write', function(param) {
  console.log('V1:', param);
});

v9.on('read', function() {
  v9.write(new Date().getSeconds());
});

The link to the node.js module is a bit confusing... But to be honest the code itself is relatively compact, and can be auto-minified (via Web IDE settings) so shouldn't use up too much space.

No, you'd have to upload to the Espruino to verify it I'm afraid - to check it more sensibly I'd really need to run an Espruino instance in the web browser :)

thingstud.io 0.3.0 released support for now for HTTP and feed processors so can work with any ip enabled Espruino no need for mqtt http://blog.thingstud.io/

Thanks!

Someone also pointed out to me that you can use DroidScript to develop applications for Android - if you want something non-webby that also uses JavaScript.

It's got built-in serial/bluetooth-serial support too...