Come watch a quick walk through of our new office before we move in. It’s a big step up from our last place where we were sitting on top of each other (however no pub underneath us anymore) . And even a bigger step from when we use to work out of Charlie’s basement. Go Crank!
Tomorrow is a big day here at Crank since we are about to move into our new office that is 3 times the size of current office!
Our new address will be :
4017 Carling Ave, Suite 302
Ottawa, Ontario, K2K 2A3
It’s on about 2.5kms from our current location. I’m sad to say it is not directly over a pub like our current location but is much bigger and brighter. Tomorrow I’ll give you guys a sneak peak at the new digs with a video walk through.
Now I have to go finish packing
Jason
As a reference, we really like the design of uControl’s home security and automation panels:
I just finished up a Lightning Talk at the 2010 Linux Symposium where I chose the somewhat provocative title
Let go of your widgets! Image based embedded user interfaces
In such a short time frame it is hard to cover all of the different reasons why including a graphic designer as part of an embedded product development team has been a challenge … so I glossed over it and moved on.
Instead, I focused on looking at why Linux is a great platform for embedded products to start with. In addition to its large developer community, Linux has near universal support from various silicon vendors. Nearly every modern evaluation board that you will get from a vendor like Freescale or Renesas (among others) comes with Linux support available out of the box.
The problem arises as you move away from hardware/operating system choices up the application stack.
A common complaint for first time embedded Linux users is that there are simply to many choices and options available to them. When you are getting started with a new technology, having more than one path forward is more of a hindrance than a benefit.
This is particularly challenging when it comes to choosing the rendering platform/technology that your user interface is going to be reliant on. Here are just a few of the choices available to you under Linux:
fbdev, directfb, Open GL/GL ES, OpenVG, x11/TinyX, QT, gtk/gtk+, cairo, skia, svg
… and the list goes on
Many of these technologies build on one another, but under Linux the graphics landscape is far from straightforward.
Unfortunately, with the way embedded user interfaces are developed today, a significant amount of time is spent translating the content and vision of a graphic designer to the actual screen content layout used in the product. This work can’t start in earnest until a particular rendering technology is chosen. Under Linux we’ve seen some of our customers completely paralyzed by this decision … so much that they’ve jumped ship to other OS technologies with a simpler graphics story.
This was bad news to deliver at a Linux conference
The good news is that we are working on a solution. Storyboard Suite alleviates the need to select a particular graphics technology or operating system or hardware. With to its flexible back end runtime technology you can continue to build your application while you make hardware and operating system selections, and the work can all be performed by a graphic designer who is ideally positioned to create and manage the product’s user interface.
An interesting case in point is our Beagleboard support. We can easily leverage three different rendering technologies on this platform; fbdev, directfb and hardware accelerated OpenVG. It is very interesting to see the small differences in general performance when you run the same application, but I don’t want to ruin the surprise so you’ll have to try it for yourself.
The good news for the Linux folks is that we run WinCE on this same board and Linux does run better out of the box!
Thomas
How to effectively collaborate on developing a GUI for an embedded product has long been an issue. Many companies try to address this issue by assigning a single resource, an embedded system engineer, to be in charge of the GUI and responsible for all changes and features. This solution works in very simple cases but has no ability to scale with larger projects or in the event your project becomes larger then first intended. It also doesn’t account for many of the new stake holders being introduced in to the new embedded development cycle such as graphic artists, UE/UX experts, marketing and product management teams. Your product’s GUI has quickly become one of the key differentiators and vital to your products success and is no longer a job left for a single resource to be responsible for.
But how do we enable all these key stack holders to work together? The challenge is that each stake holder has a completely different background, skill set and uses different tools to do their job.
This is just a short list of some of the issues :
Many informal tools such as email, instant messaging and wikis are used to attempt to solve this issue. While these each offer certain advantages, in the end they only assist in sharing information about the project, not with the artifacts and deliverables directly associated with the project itself. That is, they do not enable sharing and collaboration at the user interface design and development level, including screen designs, screen transitions, script and code management, and test suites.
At the other end of the scale, code repositories offer a formal, structured means to capture the base code represented by the project. While code repositories are necessary for any large project to succeed, and have proven to be very successful for software engineering teams in writing code (or dealing with text based files), they are not sufficient to enable the various team members on the projects we’re intending to support to collaborate and work at the appropriate level. As an obvious example, a graphic designer gets very little value from a code repository.
However with the correct development tools this problem is solvable. Here is a basic example of what a development environment with an understanding of collaboration could provide a user when doing something as small as changing the background image in their user interface. The interface displays the items in the GUI that have changed versus the version that is sitting on the head branch of the development tree at a level that is appropriate for the audience.
And to take it to the next level, allow the user to then flip to a graphical view and understand what these changes mean to the presentation.
This is a very simple example and sneak peak but in the next few weeks we’ll show you how Crank’s Storyboard Suite is enabling true collaboration for the development of embedded GUIs.
Stay Tuned!
Jason
This morning I just committed a change to the Storyboard Designer 1.1.1 code that fixes a rather annoying bug we introduced as part of the code completion where if you typed a space then didn’t type something else right away we would kick into auto-code completion mode … both embarrassing and annoying.
The editor now behaves properly and you can invoke Lua code completion by using the CTRL+SPACE keychord and not worry about spurious auto-completions.
While I was in that code, I found another platform configuration bug that was preventing us from properly showing hover information. Fixing that bug we’ve now got proper LuaDoc integration in the editor!
This is pretty nice for long Lua scripts … as you can see here you can annotate your own Lua functions with comments and they should propagate through live (after you save). The syntax for LuaDoc is pretty straightforward, looking a lot like JavaDoc/Doxygen documentation formatting and you can find a quick overview in the LuaDoc manual.
Thomas
Interesting post about the multitude of varieties and flavours of WebKit that are available that is worth a read.
What is important to understand is the WebKit is an engine, it is not a browser. Products take a snapshot of WebKit and then incorporate it into their own products with a specific set of features enabled (HTML5, SVG, Web Workers, Inspector, SQL db, …) and their own browser decorator or presentation functionality (ie Safari, Chrome, Iris, …) snapshot it, ship it and maintain it for as long as they need.
Here at Crank we have ported and optimized the WebKit engine over half a dozen times in order to accomadate different operating systems, CPU architectures and rendering technologies. No two of our ports have been the same because our clients, mostly building embedded products, have very specific needs that we cater our WebKit customization efforts towards. The needs of an in-car navigation system are different from those of a kitchen appliance which are different from those of a stereo receiver, digital printer and camera.
WebKit offers a great technology baseline that can be readily customized and ported. Some of those changes make it back into the baseline, others do not. Given our experience with WebKit I’m not surprised by the diversity of experience.
Thomas
Storyboard has an intuitive and straightforward development and runtime model.
This model is easy to keep in your head, and turns out maps very well for graphic designers, who think about their compositions in terms of layered elements of content, graphics hardware, that often provides accelerated compositing functions and software developers, who hate repetitive code and duplicated resources.
Out of this model also comes the notion of a model context or model scope. With few exceptions, there is always a valid hierarchy of model objects available (application, screen, layer instance/layer and control).
You can see this hierarchy when you look in Storyboard Designer at the Application Model view:
Given this hierarchy of model elements, you can reference data variables using the internal variables ${app:<variable_name>}, ${screen:<variable_name>}, ${layer:<variable_name>} and ${control:<variable_name>} (written here using the Storyboard Runtime notation). These variables are then resolved using the current model context to match the current application, screen, layer or control as appropriate.
Often these internal context variables are used as arguments to actions or within render extensions to refer to variable data without having to specify the fully qualified name, i.e. ${app:[<layer|screen>.][<control>.]<variable_name>, of the variable. This provides both an encapsulation to avoid unintended collisions of variables that use the same name as well as offering a degree of freedom to designers to rename model elements without having to revisit all of their actions, render extensions and data variables.
The Storyboard Designer 1.1.1 update coming out shortly will have a revamped variable selection dialog that should make the selection of these data variables and understanding the use of context a bit more straightforward. In addition, the new dialog will allow the use of a custom variable name path so that there is always the ability to override the default encapsulation offered by the app, screen, layer and control variables.
Hopefully this provides a bit of insight into what model context is and how and where it can be used within your application’s design.
Thomas
Hello Everyone,
I have had some requests to post the PSD file that I used for the Date/Time Spinner Sample. So with no further delay here it is.
To import the PSD into Storyboard simply go to File -> Import -> Storyboard Development -> Photoshop PSD File
Enjoy!
-JamieV
I know what you are thinking. With witty lyrics like that, how is it that I am not in California writing dope rhymes for Snoop? Well, I’ve always believed that you have to do what you love, and while banging out classics with Snoop would be fun and all, I love working with computers.
Speaking of computers, they require an OS to run, and I’ve been a Ubuntu user for a long time. I am not a Linux zealot by any stretch of the imagination, as I believe everyone should use an OS that they like. I prefer Linux due to the console that it offers. The command prompt on Windows annoys me to no end, so I switched to Linux so that I could use a terminal that was a little more refined. The terminal is the window to your OS’s soul, and the command prompt on Windows ironically, has become dirty and clouded.
So I found Ubuntu and I have used it for the past 4 years. It was a happy union until I read through a particular post on gnome look. This person posted an icon theme that he claimed was only for Fedora. They then went in to an angry tirade as to how Ubuntu was making things too “easy”, and becoming more and more like Windows everyday. I don’t necessarily agree with their points, but I did start to think, had I learned every thing that I could from Ubuntu? I could install Ubuntu on my laptop and get up and running in fairly short order. I know how to configure it too my liking and get around most of the issues that exist in it. So where is the challenge, and thereby the fun in that?
I figured it was time to switch to a new distribution, but what would I choose? I paid a visit to distro watch, and went through the top 25 distributions that were listed there. I found a couple that met my requirements ( mainly gnome support ), and tried them out on my home desktop machine, as switching to a new distibution on my work laptop without knowing how it performs seemed somewhat dangerous. I picked one, used it for a week on my home desktop machine, and now I use it on my work laptop.
In the end, I chose Arch Linux, and it’s been a blast to learn. The install was fairly straight forward, but I still managed to accidentally blow away two partitions on my home machine that I would have preferred to keep. It was my own fault, I was reading stuff too quickly, and not paying attention to what I was doing. It’s package management ( called pacman ) is powerful. Also, installing unofficial packages from the AUR’s is simple using a utility called yaourt. For the most part, I feel that I have more control over what is installed on my system, and there are a tonne of “Arch Wiki’s” to read. It’s best feature though has to be that it’s origin is Canadian.
It would appear that as long as there are different Linux distributions for me to try, I won’t be moving to California to be “rockin’ those beats”. Sorry Snoop.
- Rodney
| First name: | |
| Last name: | |
| Email: | |
 |
