As many of you know, we’ve been cranking on the latest major point release of ThingStudio for the last month or so, which includes: major updates to transports, UI improvements and ‘breaking ground’ on a new version of the app viewer. So, without any ado, at all, here we go.
Our second transport: HTTP
While going from 1 transport to 2 may not sound like a big deal, it’s surprisingly complex. With one transport, you can just assume ‘connection’ refers to one thing with well-defined, unchanging properties. This assumption propagates all the way through your code base. In our case this ‘connection’ assumption was MQTT.
Since day-one we’ve been planning to add multiple transports, but our most advanced users really started to push us towards not only adding another transport, but HTTP specifically. So, we’ve finally tackled this and it’s working great.
While MQTT probably remains the “destination transport” for IoT in our opinion, HTTP is both a great starting point for people new to IoT and accustomed to its request / response paradigm, there are also strong cases to be made for HTTP as a valid part of the IoT transport suite. So there you go.
Other transports we’ve got in mind: web sockets, server events, Bluetooth, COAP, not necessarily in that order. Any of these more important to you than others? Any we’ve missed? Let us know in the comments.
Inherent in providing HTTP support, and really scaling out MQTT provider support, is the need to add feed processors to handle data in all kinds of formats, make them modular and of course, easy to manage with a great UI.
To quote our feed processor docs:
Feed processor are routines that change the data going in and out of a feed into a form that can be managed by the rest of ThingStudio. There generally two types of feed processor for each transport, processors that manage incoming data, and processors that manage incoming data.
This is the name which will be displayed in the select box when in the feed properties page.
There are generally two types of feed processor for each transport. For example, for the HTTP transport, type can be HTTPRequest, or HTTPResponse, to process the outgoing and incoming data respectively.
For more details on feed processors, see our documentation.
New App Properties: CSS & JS
So, first the good news: no more “themes” as a top level object. We still feel it is important for you to be able to spin your own styles for your apps, but to have CSS as a top level object in the system, where JS was always aligned specifically to templates, was just awkward.
Now, the great news: you can now have app-level CSS and JS (as mentioned in the Feed Processors section), and template-level CSS and JS, as always.
The idea here is pretty straightforward: CSS & JS which are global to your app go in the respective tabs in the ‘edit app’ screen, while CSS & JS specific to a single template go in the ‘edit template’ screen. No surprises here.
Another New App Property: Documentation
When you start getting serious about your IoT apps, you’ll need to start providing documentation of your own; for your reference and for your customers. We’ve added a home for this, also in the ‘edit app’ screen. The editor has full support for markdown, so have at it.
IDE UI Improvements
So as we talk about the future of ThingStudio amongst ourselves, as well as where much of the IoT industry stands in late-2015, we frequently return to the fact that right now the IoT game is more about discovery than anything else with regard to delivering the scale of value expected of it.
This discovery for us also translates in to the visual language with which we present the robust, production quality capabilities of ThingStudio.
When you login, you’ll see that the “information density” of the UI for the IDE is noticably higher than in 0.2.0. We believe this will translate to a more comfortable user experience, and higher productivity in the system. We strongly believe that ThingStudio not only has to be powerful, but a pleasure to use. If you ever feel we’re failing here in one regard or another, give us a shout!
You’ll continue to see the information density increase somewhat over our next 3-4 releases, as we make ThingStudio feel more like the workhorse IDE it is. But it will always be beautiful, fast and fun to work with. You’ll also see the UI “smarten up” in some pretty cool ways. Stay tuned.
Multiples: Feeds & Connections
By adding our second transport, we had a lot to think out, including the UI & UX for managing multiple types of any top level object – a paradigm the system had never previously had to solve for. Figuring out the best way to present the ability to add multiple transports (and inherently, feed types), which would need to scale to 3, 5 or maybe even 10 or more transports, we had to find a new UI pattern to present this capability.
Originally, somewhere between 0.2.0 and 0.3.0 on our test environment where our beta testers provide feedback to us, we had the multiple transports available in the sidebar. But this created an inconsistency with the sidebar icon rhythm you are used to, and we didn’t want an icon soup by having an icon for each new transport. Plus, let’s see you make an icon for web socket that’s distinct from HTTP, MQTT, COAP, Bluetooth, server events, etc. 🙂
Breaking the user experience in this way didn’t even solve for the creation of new items of each type of object. This was a non-starter made even worse.
As Joe Sparano famously said:
“Good design is obvious. Great design is transparent.”
We went with a single list of the combined types of objects (“Feeds” includes MQTT and HTTP feeds, “Connections” includes MQTT and HTTP connections), and we replaced the previous “drop down form” you were used to with a plus-sign dropdown, which takes you directly to full-page forms where you can create new items with enough screen real-estate to think clearly.
While this may seem obvious now (it sure does to us), it was a good number of impassioned discussions in the making.
Viewer UI Updates
So as many of you who have built stuff in ThingStudio can probably surmise, the app viewer has historically been the weakest part of the user experience in ThingStudio. This release represents our first steps in creating not only a top notch user experience for the viewer, but also preparing for a native app (iOS / Android) release coming soon.
Historically, we didn’t put much focus here because we provide you the tools you need to spin your own nav structure, etc. But as we realized with widgets, it helps to give people an attractive, easy to use starting place, and let them evolve their UIs at their prerogative as their needs develop.
We rewrote almost all of the code for the viewer from scratch based on an understanding that comes from the sum of our collective experience on what ThingStudio needs to grow in to, and it’s a whole lot better. Like, by a mile.
When you login, hit the new “View App” button in the top of the left-hand sidebar to check it out. We think you’ll be pleased with the progress.
But, we’re still a long way off from where we want to be with the app viewer. We’ll be improving on the viewer with each major and minor release based on your feedback and our roadmap. The end game here is a top notch native application which is dynamically populated with your IoT apps and UIs, with everything you’ve come to expect the experience of modern mobile applications, while remaining completely flexible to the demands of your implementation.
So, those are the biggies for 0.3.0. Give it a shot and let us know what you think.
Ciao for now.