It's official. The Crank™ Storyboard™ Suite is generally available.
Here's the news release: Crank Software Announces Availability of the Crank Storyboard Suite of Embedded UI Development Solutions. If you don't have time to click thru, here are the highlights:Go to Crank Storyboard Suite for the details. Also, check out the Storyboard product videos.
The desire to have a user friendly and visually rich graphical display is no longer a “nice to have” but rather a key feature and product differentiator that can seriously affect a product's acceptance in the market place. The UI is the first—and most impressionable—part of any product.The increased importance of a modern, appealing, UI has spread beyond consumer devices to become a requirement for all embedded products, in particular in the industrial, automotive, medical, and military markets. This change is causing a paradigm shift in the embedded market and affecting how UIs are designed, prototyped, and embedded.
Up until recently, the same embedded engineers who designed the hardware and wrote the system level drivers also implemented the UIs.This has led to a proliferation of UIs that are functionally correct but a usability and aesthetic disaster. Recent products, such as the Apple iPhone, have awakened consumers to the value of innovative UIs fuelled by rich graphics, making it evident that the design of any modern product’s UI needs to be done by a professional graphics designer. The requirement for a graphic artist or UI designer as part of the product development team is now a reality.
UI designers are not embedded software developers and the development tools and environment that they generally work in are not focused on embedded products.Embedded software developers develop their UIs using widget toolkits, libraries, and frameworks.The interface layout is software written using C, C++, or some other programming language targeting a specific OS or embedded environment.Graphics designers often work in a desktop environment using advanced graphics design applications such as Photoshop or Flash. To integrate the designer into a development team, there are two practical solutions: Have the designer develop the UI with the tools they are familiar with then provide the graphical content to a software developer from the embedded team to integrate using the traditional methods, or try and use the same technology as the designer works in and move (port) that technology to work on the target embedded device
The “handoff” solution provides one approach.The graphical designer creates all of the screens and graphical content for the product then hands them to a system engineer to implement using a widget library.This approach ignores the fact that a product’s UI has both a look and feel.While the designer provided the graphical content (the look), the system engineer was responsible for programming the layout of the components and implement the interactions between them (the feel). Often, once the graphical content is provided, the designer’s role is diminished and whatever intent there was for the flow of the UI is not exposed until the entire product is assembled—potentially months later.This mismatch between the expectation of how a UI should work and how it does work turns into critical delays.Additional delays are often incurred as discussions between the designer and software developers occur around what capabilities are possible given the hardware and software constraints.
The “square peg in a round hole” solution provides another approach.In order to avoid the churn associated with the “handoff” approach, this approach allows the graphical designer to maintain control of the UI throughout the entire development process.In order for this to work the technology used by the designer is adapted to work directly in the embedded product.The burden is then placed on the embedded system and development team to overcome the challenge of adapting a technology suitable for desktop systems to work in an embedded environment. The development team spends their time implementing communication APIs, minimizing CPU and memory usage consumption, and dealing with the general performance issues caused by the introduction of a desktop application into an embedded environment.
There is a middle ground to these two approaches.It should be possible to have a development environment that enables the UI designer to develop content effectively while at the same time being sensitive to, and aware of, the requirements of resource constrained devices. A tool that would allow the designer to work with content generation tools they are already familiar with and then enabling them to add “feel” to the interface by defining the events, action, transitions, and animations that will create a satisfying user experience. The UI created by the designer should be able to move easily to an embedded system, communicate with it, and receive event notifications through the system’s existing messaging APIs.This environment would have enough awareness of the strengths and limitations of the embedded target environment, that it could guide the designer into solutions that are optimal for the available hardware, CPU, and memory configuration.
The Crank Storyboard Suite fills this hole in the market by providing a UI design tool that quickly and easily imports the designers graphic content.Import of Adobe Photoshop’s PSD files enables the graphic designer to pick up where they left off in Photoshop to start defining the system’s behaviour incorporating the Photoshop layers directly into the application design. System engineers can provide details of the target embedded system, including hardware and software limitations.This allows the designer to create content knowing in advance that he isn’t stepping outside of what the embedded platform is capable of.Once created, the Storyboard Simulator allows the designer to see exactly what their UI will look like on the embedded system without draining resources from the embedded system engineers for early verification. On the target, the Storyboard Engine is designed from the ground up for embedded systems.Storyboard Engine has a modular structure to allow maximum functionality, leveraging system and hardware services, packaged in a minimal footprint.
When the designer can maintain control of the UI and can work in parallel with the embedded engineers, you avoid the last minute UI disappointments and compromises and significantly decrease your time to market.
Click the play button to watch a video demonstration of Crank Storyboard Designer's integration with Photoshop.
When porting WebKit to a new platform, there are numerous factors to consider—here's the good, the bad, and the ugly of WebKit porting.
There are a great number of open source projects based on WebKit with many repositories to pull from. Because the decisions you make at the beginning of the porting process can end up causing you trouble later, you'll find these tips of high value.
Where do I get my source?
The main repository for WebKit is http://www.webkit.org and it contains all of the mainstream ports. If you want to be on the bleeding edge of WebKit, this is the place to be. While this tree has many branches, by using the site you'll always stay up to date. Keep in mind that when you pull from the trunk, you might not get a stable source code base, nor will you necessarily be getting what others are releasing—just because Apple has a great iPhone browser doesn't mean the head branch of WebKit will give the same browser.
Another option is to use an alternate repository such as the Origyn Web Browser (OWB) at http://www.sand-labs.org/owb. This is a port of WebKit using the OWB abstraction layer. This tree is kept fairly up to date using a mirroring and automated merge strategy. It's an attractive option based on its ease of porting since using the OWB abstraction layer means a good deal of the hard work has already been done for you. However, it's possible that this repository might not be kept up to date. Also, the OWB source code hasn't been merged back into the main WebKit branch, so if you wish to have your changes pushed back into the WebKit tree, this may not be your best option.
Building it
Once you've selected the repository, the next step is to get a working build. Crank Software recommends building a Linux or Windows version no matter what your platform. This'll allow you to get familiar with the code and build the system on a functional target. You can play with build options and compiler settings. Also, WebKit requires many other open source libraries to build and function on a target. These include sqlite, cURL, XML, XSLT, etc. Doing this build will allow you to determine which of these'll be required for your port. Once it's time to work on your own build, we find it easiest to select a similar platform and start from there. Next, look for all the ifdefs for that platform in Makefiles and source code. This'll give you an indication of how many things will have to change for the new platform.
The port
There are many areas which will require porting to a new platform. We're now going to go through the platform layers.
OS level services
The native OS must provide core functionality to WebKit, including filesystem and network access, timer facilities, date/time services, and so on. If your system has a POSIX API, then existing code can be leveraged in this area. One area that should be scrutinized is the SharedTimer interface, which creates a common usage one-shot timer. This code has caused problems in every port the Crank Software Embedded Development Consulting Services team has ever been involved.
WebView and Chrome
Your port will have to implement its version of the WebView class and associated Frame loader and ChromeClient. These pieces are the basic building blocks of a WebKit port and Crank Software recommends starting with another port's version to get a feel for things. The WebView will provide a client API to your system and allow loading of URLs and manipulating pages and content. Most of the callback and notification mechanisms come from these areas including NewWindow requests, progress notifications, security status, and so on.
Rendering
The native platform must give WebKit a way to render content to an area of the screen. This includes setting up an area of the screen—or a surface to render to—and provide all of the rendering primitives such as rectangles, lines, and polygons. WebKit renders in a way that'll benefit from a vector graphics API, but a generic 2D API will suffice. If your platform has a port of the common rendering API such as Cairo, this can easily be leveraged by your port. Consider skipping the more advanced features to get the port off the ground. Ignore scaling and alpha blending until your port is rendering basic pages.
Images
The native platform will have to load and render images. WebKit provides a common set of image loaders based on open source image libraries including libpng and libjpeg. These are generic and may not give the performance that you need. The native system can use these built-in loaders or implement their own. Also, the port must provide a way of rendering images along with scaling and tile support.
Fonts
The native platform must implement a font layer. This includes font loading, caching, and rendering. Don't underestimate this portion of the port. Most times the font layer can require more time than all of the other layers combined. If your system has Freetype support, this can be leveraged from other ports as this is a commonly used library. Keep in mind that ill configured helper libraries; such as fontconfig, can cause significant performance problems.
Unicode
WebKit makes heavy use of Unicode strings and requires a native system implementation. Many ports use the ICU library for this functionality. This is a good choice to start with, but tends to be very large and bloated. It can be reduced in size, but a single latin support shim can get the port off the ground quickly.
Render theme
Rendering of form elements and scrollbars must be implemented for each port. Usually, this means drawing buttons to match the underlying native controls for the port's UI. If you're porting to a system without a UI, then you must still implement the rendering for controls including buttons, text fields, toggle/radio buttons, and scrollbars. Start with another port, such as the Google Chrome Skia version. This'll give you a feel for what is required for rendering. To get the initial version running, don't get bogged down making a button look great—a rectangle looks fine to get the inital port running and demo-worthy.
Launcher
In order to display and interact with web pages, you'll have to create a custom launcher application. This application will configure the graphics system or native UI. It's responsible for ceating the WebView and sending mouse and keyboard events to the WebKit core. Start with a very basic launcher similar to most other ports to get started.
That's it. We've got a lot of WebKit experience. If you've got questions, contact us.
Here are links to more interesting stuff.
Do you have questions? We enjoy talking tech. Please call us at +1.613.595.1999. Or email us at info@cranksoftware.com.
