Remember the ‘C’s!

I was playing with my wife’s phone this weekend, trying to find some information and the subsequent aggravation got me thinking about 3 ‘C’s which should really always be obeyed when designing a UI, all of which tie together pretty nicely.

Consistency: Once your user has performed a task, it is crucial that similar tasks are performed in similar ways. This seems obvious, but I see it ignored all the time. One of my frustrations with the phone was that it always seemed like it was a different button I needed to hit to navigate to/from screens.

Clutter: More accurately, a lack thereof. It can be so easy to add bells and whistles and fancy things to a UI which can overwhelm and make it both confusing and frustrating for the end user to accomplish what they are trying to do with your UI. This leads to me a bigger, broader point, which is…

Clarity: The most important thing with any UI, in my opinion, is clarity. It is so important that the purpose and use of any given screen is clear to the end user. When my wife first got her phone she spent 30 minutes on the bus trying to figure out how to unlock it because it was the opposite of clear and intuitive.

Any time your user (and you need to consider all possible users, not just the ones who are already accustomed to the type of UI you are designing) struggles with the clarity, consistency, and clutter of the UI, it leads to a frustrated user who is less likely to continue to use or recommend your product, and less revenue is always a bad thing. Relating back to the aforementioned wife’s phone, the frustrations she/we have had will result in me purchasing a different type of phone in 3 months, instead of buying the same phone she has.

Using Storyboard for the First Time…

My background is in print design. If I could describe myself with software I’d say Adobe Illustrator, InDesign, Photoshop, before delving into programs I used less often like Dreamweaver, Flash and AfterEffects. So hooray for all those Adobe products, they are the tools of a graphic designer, but what to do about designing a functional app? How do you do that with Photoshop? You do not. This is the story of my first time using Storyboard Designer.Storyboard Designer is Brilliant

With my background in print design I’m the sort of guy that felt special when I made buttons with rollovers. The idea of me creating is almost ridiculous. Starting was easy, I downloaded a 30-Day Trial and installed Storyboard Designer. Then I opened Storyboard Designer… *GASP Different Software Splash Screen! entering the unknown.

I think I had a fairly typical reaction to Storyboard if you consider that I’m afraid of change. I started a new project and I messed around until I got to a point where I didn’t know what I was doing anymore and then I ran away, not literally, just to reddit and watched some new movie trailers.

When I decided that I would Storyboard a second time, I went back to the Crank Software website and procrastinated by watching videos. One video that stood out to me was how to import a Photoshop file. That sounded promising because:
a) I know how to use Photoshop; and
b) it showed me how Storyboard integrates with Photoshop

There was also an Animation video which was interesting because:
a) it was quick and not all that complicated; and
b) it sounds super impressive to print-designer friends1 if you can make an app AND it has animations

With these videos I was just copying everything I saw. I would reload the videos, pause them while I caught up following along, then continue, pause, catch up etc. Things were going much better than my first attempt. Overall it was smooth sailing, but it was a little awkward being in a new place for the first time.

A new software environment had all these new views…

  • Properties View
  • Actions View
  • Variables View
  • Application Model

I made the transition from confused individual to self-proclaimed genius when I grasped that a layer in Photoshop isn’t a layer in Storyboard. These were some slow realizations that came to me:

  • A Layer in Storyboard is kind of like a Group Folder in Photoshop that you use to keep stuff together
  • A Control in Storyboard is kind of like a Layer in Photoshop.
  • Controls were just boxes that had images or text in them which is a lot like working with InDesign or Quark.
  • To plan and organize an app is similar to how you would plan and organize for a website.
  • A project folder in Storyboard is really similar to how InDesign projects are structured with a folder for images, fonts etc.
  • The Application Model is basically like a giant Photoshop Layer Palette
  • • All of the above… enlightenment.

The Application Model in Storyboard made me think about the Layers Palette in Photoshop. They’re very similar except in Storyboard you could put more types of ‘stuff’ in there, Screens, Layers, Controls, Actions, Variables and Animations. You can change the order of ‘stuff’ by dragging it up and down in the stack.

At the time, my brain was overheating with all of this new material. I would compare it to going to party when you meet 10 people for the first time and you try to remember all their names… difficult. If there was an inner monologue of me trying to keep track of what I was working on it would have sounded something like this:

… so I just made a variable, and the variable belongs to that control… which is kind of like a photoshop layer. If I have one of these action/event things happen… like touching that button control thing, it’s going to change the value of the variable and that’s going to make that control thing change.

I’m happy to report that after spending more time using this tool, that everything is more familiar and less awkward. If my Present Day Self had to show my First Time Storyboard Self how to use Storyboard I would start by saying…

Storyboard Designer = WYSIWYG design of user interfaces.

Then I would explain how everything goes together in Storyboard’s Application Model: Application – Screens – Layers – Controls. Then I would show how to organize a Photoshop file before importing into Storyboard.

After that, I would spend a lot of time looking at the Properties View and talk about Variables. Understanding properties and variables makes it easy to show how those co-relate to actions and animations. All of that makes it easier to see what’s happening on a whole when you do something like pressing a button to move to a new screen with other content. It was pretty simple after I understood how these things were connected.

The more time I spent with Storyboard the more it made sense. On, there’s documentation and a forum that can answer a lot of questions you may have. Another thing that I found really helpful were demos. You’re just looking at how someone else has done something and can learn from it as an example and apply it to your own work accordingly.

In my opinion there’s no such thing as a stupid question when you’re learning how to use Storyboard. Of course I would say that because I had a lot of questions starting out…
…how can i
…where is the
…why does the
…are you able to

Storyboard has similarities to programs you may have used, and it is different in several ways too of course. The more time you spend with this tool the better it gets. To export a finished project and run it as an app on an Android tablet is a satisfying feeling. Being able to achieve this sounds like a lot of work, but it doesn’t take as long as you might expect.

Try the 30-Day Trial, and install Storyboard Designer and see what you come up with.

1 print-designer-friends — realize it’s possible to create apps with dynamic content, but they think it requires magic and science working in harmony, because they spend most of their time with paper.


One of the things that I find most interesting about working on our  product is watching the evolution of that product.  In the beginning the focus is on the necessary features that your product requires.  The reason for this is, well, because they are necessary.  In our case it was the Storyboard runtime and tooling that could generate files that the runtime could understand.  Obviously this is done because it’s nice to have customers that can use your grand vision.

After that,  features are added to both the runtime and the tooling at regular intervals.  Sometimes they line up, and sometimes they are independent of each other.  For example, adding a specific type of render manager, i.e. DirectFB or OpenGLES in the runtime,  does not have any sort of bearing on the tool, whereas adding in collaboration functionality to the tool was done with no impact on the runtime.  However, adding something like rotation at arbitrary angles, or thick line support has an effect on both the runtime and the tool.

What I find interesting about how the product is evolving is how the features seem to be added with a certain classification in mind.  At the start it was about getting something to run on the target.  Then it was about tool and runtime integration.  Following that it was about pulling in existing projects or pieces of artwork in to our tool for deployment.  Allowing multiple people to work on the same project was the focus after that.

I think the next focus for our product will be communication between the runtime and the tool, and having the runtime provide feedback to the tool about what is happening in the runtime environment.  If this turns out to be the  case, then our product evolution has followed a path of run on the target, project generation, team development, with runtime feedback and information the next step.

I wonder if there is a pattern to product development and evolution?  Maybe every software product follows a similar path.  Much like there are design patterns when writing code, maybe there are design patterns for software projects.  This could be the case, but it would require a little more investigation on my part and I may look in to it at some point.  Until then, lets just see what group of features Crank puts out next for Storyboard.


mmm … Frozen Yogurt

Hello everyone. I haven’t checked the temperature for the rest of the world but man it is hot here in the great white north. For a country known for skiing, igloos and dog sleighs, it sure is abnormally warm for this time of year. I’m just hoping this is not a taste of how the rest of the summer is going to be. To quote Robin Williams in Good Morning Vietnam “It’s hot! Damn hot! Real hot! …”

Nothing like frozen yogurt to cool things down but it seems that an Android 2.2 release by the name of Froyo has heated things up. Google states that the web browser in Froyo beats every other mobile browser around. The guys over at pocketnow wanted to see what this claim was all about and put a video together to compare Safari, Froyo and Opera Mobile.

Everyone by now has read or heard of the “Thoughts on Flash” letter from Steve Jobs, Apple’s CEO. He basically states that Flash does not perform well on mobile devices. Well he is definitely onto something and quite frankly it is something we have all struggled with in the embedded world. Resource constrained embedded devices have a hard time running Flash well and the proof is in the pudding when watching the video from the pocketnow guys. Flash was created to run on desktop machines, not mobile/embedded devices.

Well I’ve lost about 5 pounds writing this blog post. Off to the store to buy some more frozen yogurt 😉


Storyboard 1.1 released

Image locality

Locality is an interesting to think about and exploit when designing algorithms for image processing.  For normal data processing a simple MRU cache is a common solution, taking advantage of similarities as you linearly traverse a data set.  When you start thinking about image processing however, locality is suddenly two-dimensional.  Considering the pixel above you is equally as advantageous as considering the pixel to your left.

For example, consider turning a 32 bit-per-pixel image into a paletted one. Determining the closest match in the colour palette for each pixel can be an expensive task.  Caching recently computed values can help, but this falls apart if you are processing large images (say 1600×1200) linearly.  By the time you process pixel (x,y), the computed value from (x, y-1) has long since been removed from the cache, and there is a fairly good chance that final palette index will be the same.  A simple change in processing order can make all the difference.  By processing the image in MxM blocks (Choose M to suit your cache size) and iterating through the y direction first we can take advantage of the bi-linear nature of locality for images, greatly improving cache efficiency and, as a result, processing time.

Techniques like this are really important when designing software, especially graphics software, for embedded devices.

Higher end graphical features such as Gaussian filters and anti-aliasing can add a lot of pop and polish to your UI, but are often too computationally expensive for deployment on embedded devices, where every CPU cycle counts.  By being creative with implementation decisions and carefully choosing your optimizations, you can greatly reduce the cost associated with highly desirable features, allowing you to provide a crisper, nicer looking application.

— Chris K