One of the questions that’s come up several times in talking to other developers about Mulberry is this: How is Mulberry any different from all of the other mobile app development frameworks that are out there?
At Toura, we’ve been developing and using the technology behind Mulberry for more than a year, creating apps for clients that range from museums to major media companies. Because our core business is centered on the rapid creation of content-rich apps, we focused our development efforts on reuse from the start. That focus led us to an opinionated framework, one that makes some assumptions about the kinds of applications developers will build with it and about how those applications will be built.
Being opinionated results in a framework that dramatically reduces the effort that’s required to develop an app, and subsequent similar apps are easier still, because it’s vastly more likely that functionality developed for one app can be reused down the road.
Mulberry comes with lots of components and page layouts that use those components — making it easy to create content-rich applications that incorporate images, videos, map locations, and more — and it also provides simple APIs for creating custom components and adding them to the underlying framework. Custom and built-in components can be arranged into pages, and those pages can be enabled with pre-defined or custom interactions between components. Components neatly encapsulate their DOM structure, behavior, and state, and expose predictable interfaces that make them easy to integrate into applications. Mulberry apps aren’t about wiring up buttons and lists and grids — they’re about defining the interactions between far richer components, and then customizing the presentation layer to create a unique experience.
For Toura, all of this means that creating a particular kind of app has become a reliably repeatable process; more importantly, adding custom functionality to individual apps is also a reliably repeatable process whose results can be readily reused across multiple applications and platforms. Units of functionality — a Twitter feed component, say, or a component that displays a location’s name, address, phone number, web site, and map — take the place of DOM nodes as the building blocks for applications, and they can be mixed and matched and connected in any combination that makes sense.
We’ve placed a lot of value on being able to define new functionality, creating
mulberry.capability that let us set up new
components and interactions without impacting existing functionality. We’ve
also been diligent about keeping our presentation layer very loosely coupled
with the behavior and data layers. All of this means that we can dramatically
alter the “look and feel” of an app while leaving the underlying functionality
largely intact, and create new experiences with shockingly little code.