Reimagining UI Design at the Smart Kitchen Summit

***I asked Nick Deeble, our enterprising sales manager, to pass along his thoughts and musings regarding his recent attendance at the Smart Kitchen Summit. Rarely short on words, Nick had the opportunity to talk with a lot of attendees about their challenges with developing UIs for appliances.***

Smart kitchen Crank Storyboard Suite embedded UI development

We recently had the privilege of being a sponsor at the Smart Kitchen Summit, an event that’s a bit of a departure from the shows we regularly attend. SKS is a specialized event, bringing together everything from the latest technologies impacting cooking to robotics to organic farmers and evolving food distribution methods.

Jason Clarke, Crank Software co-founder, participated in a panel discussion “Exploring Voice and AI-Powered Interfaces For The Kitchen.” As an industry veteran in embedded UI development, Jason has years of experience and understanding of user interaction with embedded devices. He’s seen the evolution of technology as many companies try to solve the common problem of visually representing the communication between people and products. Crank’s mission is to simplify bringing that interaction to life. Check out the following interview that Jason did with the great folks at The Spoon:

In addition to the speaking opportunities, we showcased a variety of kitchen appliance demos at the show and had the opportunity to meet with attendees to discuss their challenges with designing and developing products for the embedded market. Included in our demos was an oven control panel provided by GHSP running a UI designed and developed using Crank Storyboard Suite. Feedback on the demo was positive, with attendees being impressed by the aesthetic of the graphics, the fluidity of the animations, and the intuitive nature the User Interfaces Crank demonstrated. We received a lot of compliments about the performance, smoothness, and responsiveness of our UIs. One of our customers, who was showcasing a new appliance with a UI built in Storyboard, popped by our table to thank us for our customer focus and to point out how much better their UI was than the others they were seeing. We will never get tired of that type of feedback.

Challenges in designing for the smart kitchen

A few common themes popped up in our conversations with attendees:

  • Creating a professional and differentiated user experience for embedded devices can be challenging given tight timelines.
  • Because design change is inevitable and there’s a need to continually update UIs to respond to stakeholder feedback and evolving product scope, we had a lot of questions about how we enable iterating and testing UIs using Storyboard to ensure the delivery of a high-quality product throughout the lifecycle.
  • Embedded design and development often requires support for multiple markets, language translation, and custom branding.
  • There’s a shift from home appliances to home experiences. Connecting appliances together, connecting them to the internet, and communicating with them through a mobile device, are all part of the evolving vision of the kitchen

These were just some of the challenges that many appliance manufacturers wanted to chat with us about to hear how we’ve has built these capabilities into the Storyboard Suite GUI development framework. We are going to address this functionality and our thoughts on the future of designing and developing for smart kitchens in a future blog post.

If you want to see multi-market Storyboard Suite demos on your favorite platforms, download one of our easy-to-run demo images.

As always, we provide a full-featured 30-day evaluation for you to test drive Storyboard Suite.


Thanks NXPconnects!

The big news for NXPconnects attendees last week wasn’t the scorching heat wave running through San Jose, rather it was the announcements, demos, and talks surrounding autonomous vehicles. Visitors to our booth were treated to our stunning 3D automotive cluster demo running on the NXP i.MX6QuadPlus, along with other examples of how we accelerate and improve user interface (UI) development.

Most visitors to our booth were hardware and software practitioners curious about how Storyboard Suite improves UI development and what markets we target. While Nick answered the business reasons, Thomas demonstrated the real-world implications on a live system:

  • You can go from design to deployment in minutes, with Storyboard’s Adobe Photoshop import tool and variety of deployment methods, including running on a desktop simulator or using SCP transfer to real targets
  • By allowing designers and developers to work together in the same environment, neither is dependent on or gets delayed by the other, resulting in a much faster time to release
  • Talking about Photoshop again, the final UI is much more rich and engaging because the designer’s intent is put into production – no more forcing the UI to fit pre-packaged widgets or limiting it to software constraints

People were immediately hooked by taking a design to target quickly and it led to questions about what platforms we support (everything from MCUs to MPUs, with little compromise in UI features) and production readiness (every deployment is production ready). Our partnership with NXP has never been better and together we can help you realize UIs that are beautiful, engaging, and highly performant.

Our partnership with NXP has never been better and together we can help you realize UIs that are beautiful, engaging, and highly performant.

Stay tuned for news on how we support the NXP i.MX 8 series of processors to get maximum UI performance on powerful, highly efficient boards.

To learn more about Storyboard Suite, check out our latest on-demand webinars.

Click to watch

Webinar: A better way to build UIs with Embedded Artists

Crank Software & Embedded Artists webinar


Whether you’re an embedded user interface (UI) designer, developer, or team lead, you’ve probably come across these issues before:

  • Designer: The final product doesn’t look like the design I created
  • Developer: Finding or building a board that fits our functional, performance, and environmental requirements is nearly impossible
  • Team lead: Do I delay the release to get the UI design just right? Can I accept the tradeoffs between design and development? Does my budget allow for the board my developer wants to build?

The embedded UI development process shouldn’t be this hard and, in fact, it’s pretty easy to overcome all these issues and more.

Accelerate UI development now

On June 1st, join Crank Software and Embedded Artists to learn how to bring designers and developers together on low-risk, low-cost hardware using Storyboard Suite on NXP i.MX 7-based computer-on-modules (COM). Crank Software will demonstrate features that support ease-of-use for designers and simplify the challenge of inevitable design churn and iteration. This includes: design import and re-import from Adobe Photoshop, creating vibrant animations via the built-in timeline, and seeing how to quickly deploy and debug your app on real embedded hardware.

Be fast like this cat

Deliver UIs as fast as this cat

Embedded Artists will explain how their COM boards and display adapter solutions accelerate development across display types and resolutions, making it easy to focus on your core business and deliver applications faster. This build or buy calculator illustrates the costs of building your own boards.

3 reasons to sign up

  1. Learn how to reduce (or eliminate!) the churn between design and development
  2. Find out how purpose-built COM boards and adapter solutions accelerate time to release
  3. If you don’t believe the words, see how quickly it can all be done via live demonstrations

You can also ask questions at any time to help understand how all this fits into your team.

Accelerating UI development with Crank Software & Embedded Artists
Thursday, June 1, 2017
8:00 A.M EDT or 1:00 P.M EDT


If you can’t attend the live webinar, don’t panic. Our webinar recordings are always available here for on-demand viewing.

Storyboard Suite vs. Qt, part 2: Which is better for embedded?

Storyboard & Qt comparison 2

(read part 1 here)

Last time we compared Qt and Storyboard Suite across three criteria: designer workflow, resource usage and performance, and platform scalability. In this second and final post, we’ll cover:

  1. Application architecture
  2. Testing your user interface (UI)
  3. Time to experience and overall cost

It’s important to remember that Qt is an excellent framework that performs well across a wide variety of applications – there’s a reason why it’s so popular. However, we’re just focusing on embedded devices here and not making any claims that Storyboard is better across all types of apps.

Application architecture

By default, a Storyboard application enforces a clean separation between the user interface layer and the backend, with a well-defined data model and events API in between. The data model is generated from the UI design and is used by the Storyboard engine at runtime. This architecture leads to a robust, portable, and highly optimized application that also lets the designer and developer work in parallel to build the app. They can literally work on the same application at the same time because they’re working on two self-contained components.

This separation results in faster testing and iteration of both sides of the application and allows the designer to change the UI – say, after design reviews or user testing – with little to no impact on the code underneath. Photoshop Re-import Design IterationWe’ll discuss the benefits of this down below.

By design, Qt allows you to create your own application architecture in essentially one of two ways. Using standard Qt distributions (i.e., not Qt Lite), you get one monolithic application that has the UI and underlying libraries tightly coupled together. You can enforce your own clean separation between the UI layer and backend but, in our experience, we find that most teams can not or will not invest the time to do it. They’d rather get their UI up and running quickly than focus on defining and implementing best practices for architecture and maintenance.

“You may want to think about separating the presentation from the business logic to make it easier (or at least possible) to move the code, say, from the desktop to a touchscreen interface (which might mean moving from widgets to QML).”
– Top 10 Scary Qt Mistakes, ICS Insight blog

The second option that Qt has recently announced is Qt Lite, a trimmed-down version of Qt that changes the include philosophy from “everything included” to starting with the minimum deployable configuration and letting you add additional modules. Qt Lite comes with a new configuration system that lets you declare the content you want from each module and includes a new, software-based Qt Quick 2D Renderer as an alternative to relying on hardware that supports OpenGL. While this customizability is powerful, it still takes knowledge and time to act on it, and the framework currently supports only ARM Cortex-A SoCs, with Cortex-M7 MCUs being considered for the future.

Testing your UI

There are a few methods for testing Qt applications from a UI perspective:

  • Qt Test – Qt’s built-in testing framework, including basic GUI testing for mouse and keyboard simulation. Qt Creator includes an autotest feature that builds on Qt Test.
  • Qt Quick Test – Qt’s built-in testing framework for QML applications.
  • Build your own tests or use any number of C++-based test tools, such as Google Test or Squish by Froglogic.

Storyboard Suite offers two ways to support your application testing: tools built into the product and APIs that expose methods and data to include in your own test framework. For example:

  • Testing the UI: Storyboard allows you to capture and serialize the complete event stream between the UI and runtime, letting you dump data to the terminal or use the included sample application to play back the stream. You can also inject events into the application via the iogen tool. These features allow you to run functional, performance, and memory tests across a variety of inputs and outputs.
  • Identify UI changes: Storyboard provides a screen capture plugin, letting you perform pixel-based comparisons between different versions of the UI.
  • Deep performance testing: The Storyboard logger plugin lets you capture various application performance metrics, such as redraw times, action execution times, and event processing times.

These tools (and more) are useful for developers but what about designers?

To review, validate, or simply show off, designers can use the built-in simulator within Storyboard (which actually runs a version of the Storyboard runtime built for the host computer) or quickly run on real hardware in just a few clicks. Storyboard_Suite_DesignerWith Storyboard 5.0, there are additional options to execute applications direct-to-target via SCP or as a standalone Microsoft Windows executable. And since there’s no cross-compilation with Storyboard, you can run it on multiple target types, such as Android or iOS mobile devices, if you want to pass your designs around the team for feedback.

Speaking of which…

Time to experience and overall cost

We coined the phrase “time to experience” to mean the time it takes to get an application from design to runtime, letting the designer show off and validate their creation with stakeholders. With Qt, the designer must work with a developer to realize their design in code and deploy it to the target hardware. This usually involves back and forth between the two as the design has to be tweaked to fit into development constraints and it definitely includes all the hiccups of debugging and running a real application.

Qt has recently released a beta version of a Photoshop customization and synchronization feature but it looks like it’s limited to Qt Quick Controls and not the entire UI.

With Storyboard, time to experience is much faster because a developer isn’t actually needed – the designer simply imports their design from Photoshop, adds any desired animations and behavior, and runs on either the built-in simulator or real hardware. This video shows how you can take an existing design and deploy it on an NXP i.MX board in less than 12 minutes…real time!

Storyboard also allows you to tweak some or all of the UI design and re-import the changes for immediate validation, as in this example of two different versions of the same UI (click to enlarge):

Photoshop reimport

What about time to release?

Comparing debugging, deployment, and testing times between Storyboard and Qt is a challenge, as it depends on the application being built, the experience of the people building it, etc. It also depends on what is being built, as Qt includes APIs for Wi-Fi, Bluetooth, database integration, and more, while Storyboard is purpose-built for UI development. When we focus strictly on UIs, two things we can compare are the iterations and handoffs that occur between design and development.

Typically, and one can argue this happens 100 percent of the time, designs are handed off to developers and UI/UX practitioners don’t see it again until later on, sometimes waiting until alpha or beta product testing. This siloed approach, in which there is a complete loss of design control, creates development delays as the designer tries to adapt UI features for a product that’s getting closer and closer to release. It would be fair to say that the developer wields a lot of power here, as release timelines get closer and “good design” is sacrificed for “code complete.”

Traditional vs. Storyboard workflows

Comparison between workflows (click to enlarge)

With Qt, there are two implications. First, UI elements will look like any other Qt application, unless additional time is spent to customize the look and behavior. Second, delays are introduced into the timeline as designers and developers go back and forth to achieve a compromise between design intent and what the code can actually do. Try imagining how long it would take to transform a complete Photoshop layout into a C++ Qt app.

With Storyboard, the designer and developer work in parallel within the same environment right from the start and, most importantly, the final UI reflects exactly what the designer intended, in look and behavior. You don’t have to imagine transforming a Photoshop layout into a runtime application, Storyboard does it for you. There are no back and forth delays and, with the other tools that Storyboard provides, such as Photoshop re-import, design compare and merge, the animation timeline, and simulator testing to name a few, every step of the design to development process is streamlined.

“We had three months to deliver on our technology concept car for the Consumer Electronics Show, and choosing Crank’s Storyboard Suite to develop many of our UI components proved to be an excellent decision”
– Andy Gryc, automotive product marketing manager, QNX Software Systems Limited, a subsidiary of BlackBerry

As far as cost is concerned, it’s important to consider that while Qt for Application Development has both free and commercially-licensed versions, the embedded device version, Qt for Device Creation, is available only under commercial license. You can see a license comparison and pricing of Qt options here.

For both Qt and Storyboard, the actual cost to you depends on the type of license and number of development seats. The overall project cost, however, is dependent on how many cycles of design, development, and testing you go through to release your product.

The choice is yours

Between this post and the last, we hope you have enough information to decide which UI development framework is right for you. If you’ve taken the time to read them, great, otherwise, the tl;dr is:

  1. To rapidly create lean, high-performance embedded UI applications that match designer intent for aesthetics and user experience, across a wider variety of platforms, choose Storyboard Suite.
  2. To create embedded UI applications with a pre-configured software stack that reduces work for features beyond the UI, choose Qt for Device Creation.
  3. To get the best of both worlds, check out how to integrate Storyboard Suite and Qt.


Storyboard Suite vs. Qt: Which is better for embedded?

Storyboard & Qt comparison

(read part 2 here)

Given that we’re in the embedded UI/UX development space, a question that often comes up is: How does Storyboard Suite compare to Qt? The quick answer is that there’s no comparison – Qt is a large C++ library of functionality that includes many things and designed to let you do many things, while Storyboard is a purpose-built platform for fast UI development and highly optimized performance. Not to mention that Storyboard also integrates with Qt, so it’s not like the two are mutually exclusive.

Yet, the popularity of Qt is hard to ignore so it’s worthwhile to go beyond the quick answer and explain exactly what makes Storyboard different.

We’ll take a look at a number of factors, including embedded UI design, programming, and performance, plus provide some real, clarifying examples. As always, feel free to comment or ask questions below – we want to make sure you’re getting as much information as possible to make the right choices.

We’ll cover the following topics, starting with 1 to 3 in this post and leaving the rest for part 2 here:

  1. Designer workflow
  2. Resource usage and performance
  3. Platform scalability
  4. Application architecture
  5. Testing your UI
  6. Time to experience and overall costs

Designer workflow

If you’re a designer, it’s safe to say that you would rather focus on creating the best user experience than figuring out Qt object properties, sizes of data types, and build specs. Storyboard makes sure both designers and developers are supported with tools and workflows that are familiar and require little effort to learn.

To make the UI design process as powerful and as painless as possible, Storyboard gives the designer these tools:


By allowing designers to work within Adobe Photoshop, import the results, and run on the actual hardware, Storyboard eliminates the compromises traditionally made when converting from design to code. If you have a button colored, shaded, and cornered just as you like it, it’ll look exactly the same in Storyboard.

Qt, in contrast, forces designers to think and act like a developer, requiring them to not only understand markup language and text editors but also use widgets that have the same look and feel as every other application written in Qt. Qt widgets are customizable, of course, but that incurs time and cost and it would be nearly impossible to find a designer willing to do it.

Plus, custom widgets aren’t as easily maintained as using the Photoshop re-import and graphical compare tools in Storyboard. These let you iterate designs, compare differences between versions, and select the objects you want, all within a visual, WYSIWYG interface. This reduces the time and frustration of going back and forth between designer intent and developer reality.

Qt Creator

Qt does have a visual layout and form designer called Qt Creator, which some say eases the UI design process. The key thing to think of here is that Qt Creator is an integrated development environment (IDE) first and foremost, offering pre-packaged UI elements and requiring that you operate like a developer – quickly moving from the visual interface into text editors, properties, and C++ code. Qt Creator does ease UI layout for a developer but it doesn’t provide nearly all the design, layout, and animation capabilities that a designer needs to create amazing UIs.

Adding animations

The look of a UI is half the story, the other half is adding animations and behavior. Those familiar with Qt will know that animations are specified in code, such as object states and transitions defined through the methods and properties of the QML language. The typical workflow involves coding up logic in an editor, testing the changes, and iterating until you get the experience you want.

In Storyboard, animations are added using an animation timeline similar to what you would find in any video editing tool. This makes it easy to manipulate what the animations are doing and see the timing relationships between elements. Storyboard also provides an animation recording capability, letting you drag, drop, and change the state of objects in the visual editor for playback at runtime. It’s the next best thing to a digital camera!

Storyboard uses Lua scripts for more sophisticated object behavior and such things as event handling between the front and back ends of the application. Lua is very popular among game developers and has simple semantics that are easy to learn (read Learn Lua in 15 minutes by the makers of the Corona game SDK).

So, would you rather work with the true image assets, animations, and behavior or an abstract source code representation of your UI?

Resource usage and performance

We’ll cut to the chase here: the Storyboard runtime footprint is a fraction of Qt’s, has faster render times, and supports a larger number of platforms. The reason is simple: a Storyboard app is simply a data model and engine, both optimized with a reduced semantic set and tuned by us to squeeze the best possible performance out of the specific operating system and hardware it’s running on, including specialized architecture and graphics acceleration. There’s also no resource-hungry Javascript engine to deal with.

In other words, we’ve spent the time to ensure that the Storyboard engine runs fast and that your application consumes the least amount of resources – the golden ticket when it comes to embedded computing. Storyboard also has a plugin-based architecture, meaning you can configure the app even further to reduce memory consumption.

Qt has a large memory footprint and, typically, pulls in many framework libraries to bloat application size further. While it does offer hardware-based graphics acceleration, support is limited to a few platforms and sometimes relies on software fallbacks to get things done, which is less performant and offers little insight into performance characteristics.

Tuning Qt

Now you might be thinking that Qt is also tunable, letting you customize build configurations, how libraries are linked, memory allocation, and so on (you can read how to do it on Qt’s site here and here). While this is technically possible, you do need two things to succeed:

  1. Knowledge and experience with QML, C/C++, compilers, and target-specific performance measurement and testing
  2. Time

To give you an idea of the time needed, read the two pages from the Qt site and estimate how long performance tuning will take for your app.

Or, download the free version of Storyboard Suite now and get a highly optimized runtime specific to your environment without any effort.

Platform scalability

Beyond performance, there are two more things to consider when talking about how well a UI framework suits your chosen operating system and hardware platform. Will the app actually run? How difficult will it be to move the app onto different platforms?

Out of the box, a Storyboard app runs on a variety of platform types, from high-performance, multi-chip microprocessor (MPU) boards to single-chip, resource constrained, microcontrollers (MCU). This is possible due to the optimized, platform-specific architectures and Storyboard engine discussed earlier. You can try running Storyboard at both scales yourself, with this MPU demo image and this MCU demo image (you can run these directly on the target, without downloading Storyboard).

Running Qt on an MCU board is possible but it would take some time and knowledge to tune it effectively for the processing power and memory available. Lower-end MPUs also struggle due to resource limitations, leaving mid- to high-end systems as the range where Qt can run with less tuning effort.

Platform portability and support are important, as today’s product may be running Linux on an MPU but tomorrow it could be ThreadX on an MCU, as production scale and costs increase. Qt is a rather large library with many dependencies, so you should consider its suitability for not only your current hardware but future plans as well.

This covers the designer’s workflow, performance, and scalability. Read the second part of this post, discussing architecture, testing, and overall time to delivering your best UI experience, here.

Storyboard evaluation