Styling Your Connected App: The Elements

in features


Learn about the CSS stack powering the ThingStudio app viewer, and some basic styles to pretty up your app.

As you probably know by know, apps are the basic unit of work in ThingStudio. Think of them as a “box” for related connections, feeds, templates, feed processors, CSS and Javascript. And this entire “box” is available simply by accessing a URL (if you’ve chosen to make the app public or sharable): No programs to install, no configuration required, just pull up the URL and you’ve collected all the resources you need to run your connected app.

While less is more, it is also actually less

With version 0.3.0, we’ve taken a nuanced approach to the idea that “less is more“. We give you a solid starting point for your app, so that even on day-one it looks great, while keeping those styling queues to a minimum, and giving you the flexibility to take your app in any direction you want.

What does this really mean from the standpoint of the technology? The following:

  • Attractive starter nav: When you save your first few templates and load up your app (click “View App” in the sidebar of the IDE), you’ll see you have a nicely styled menu for your templates, and there are some basic animations taking you from one screen to the next. These should give you a nice, attractive baseline from which to work
  • No more Materialize framework in the app viewer: In prior releases, the Materialize framework which we use in the IDE leaked (intentionally or unintentionally) in to the app viewer. By closing this leak, we have essentially removed all but the bare minimum of styles from the viewer. This was one of the important reasons we completely rewrote the codebase for the app in 0.3.0.
  • Style-free (more or less): What this means is that aside from the fairly element-specific styles we’ve written for the default template menu, the header and the footer, your app is completely unstyled (i.e. no CSS).

Why we did this

ThingStudio is a two-sided solution: 1) an IDE and 2) an application runtime. Our entire technology stack is aimed at developing production-quality applications, while providing the UX to enable earlier-stage IoT developers to experiment and build as well.

And we couldn’t very well call ourselves “production quality” if you had to code around an entire frameworks’ worth of built-in CSS styles and Javascript. So, we tore them out, leaving you with a great looking skin as a starting place.

If you want to add Materialize back in to your viewer, simply include it via the CDN in your app / templates.

But what if you aren’t a web designer?

Some of our users perform feats of magic with CSS as if it were a function of their body, while others are C+ wizards – but couldn’t write a CSS selector to save their lives.

So, the flip-side of our objective to remove unnecessary styles and Javascript from your apps is that those unfamiliar with CSS may need a little guidance to get up and running. We’ve put together a quick list of basic styles that will get you started. If we’re missing anything, or if you have any questions on this, let us know in the comments.

Where to add these?

Since we are talking about global styles here (global to your app), we’ll want to add these as app-level CSS. To add them, navigate to the “edit” screen for your app (click “Apps” in the sidebar, then click the pencil for the current app – app must be active to edit). Once there, click on the CSS tab to add these styles:

Basic niceness and typography

Here are some helpful selectors and styles to help you get started:

The Grid

While we want to stay out of your way, a basic responsive grid is a no-brainer in late-2015, and we couldn’t in good conscience leave you without one. If you want to make your own grid, have at it. If you want to use ours, here you go:

The hierarchy looks like this:

  • There’s an optional .container
    • There’s a .row
      • Then a .col .sX .mX .lX

With the “X” above being replaced by the number of columns you want that element to take up at small (smartphones), medium (tablets) and large (desktop) screen sizes, numbered 1 through 12 (12 being full width of the containing element. The sX, mX and lX specify these values for each screen size.

Here’s a simple example:

For those of you familiar with Materialize, you will notice is it pretty much the same thing.

Check out our documentation here for more, and the source Materialize documentation here.

What about the header and footer?

At the moment you cannot remove the branding in the header or the menu in the footer (this requirement is true for users on the free tier of ThingStudio). Soon you will have the opportunity to build your own custom nav, and footer, as we roll out paid options with more powerful features.

At some point in the near future we will offer some sort of premium tier which will enable you to use your own branding throughout. In the mean time, there’s plenty that can be done in the app as it stands now.

Next Steps

There will be a native application for both Android and iOS available in the next couple months, giving you access to each device’s native APIs in your ThingStudio apps, not to mention access to your device’s full screen real estate.

Tell us: What do you want from the app?

Now we want your feedback:

  • Should we be adding default stylings for any other elements besides the template menu and the grid?
  • Have you used the ThingStudio app?
  • What is great?
  • What stinks?
  • What is missing?
  • What would make it more usable from an enterprise standpoint?

Paul likes to work on growth, product & design. Tweets occasionally @paulisloud.

Leave a Reply

Your email address will not be published. Required fields are marked *