While working on the new version of ZK the question kept popping up, what do people want? If you could improve ZK, what would you do? One thing kept coming up time and time again, that was to further our support for mobile platforms such as tablets.

One of the interesting pieces of feedback which resonated with me personally and the rest of the team was writing an application and have it optimized to run on multiple platforms.

With current solutions on the market offering a separate component set to create mobile applications this is not possible as a separate component set would require either another page to be written purely for mobile devices or an entire new application thus giving the implementation team(s) more work.

The following sections outline why we believe that having a framework adapt to different platforms is a better approach.

Developers should be lazy, frameworks shouldn’t…

If you’re not a lazy developer, you’re doing it wrong…

Hlade’s law states “If you have a difficult task, give it to a lazy person; they will find an easier way to do it.” Thus lazy developers are the most successful, they are the ones who search for the most productive way to fulfill their goal.

So we want our developers lazy but not our frameworks. Frameworks are there to take the load of the developer so a framework which doesn’t want to the work is generally worthless.

In the UI realm having separate frameworks for different browser implementations, form factors and input methods is a relatively lazy approach from a framework. A framework should support the most popular browsers, form factors and input methods in one package. If a developer has to use multiple component implementations for each device that he wants to implement then it means he is using more time than he should be.

Too much risk, so we do the work for you…

Separate component sets are easy to implement…

For ZK at least separate component sets which provide support for smartphones and tablets are easier to implement. To understand this statement we need to look further into the history of implementing mobile support in ZK.

Originally we were producing a separate component set named “ZK Touch” which was going to be a component set for supporting touch devices. Things were looking promising and just one of our developers was able to implement core components in little over one week.

However, upon releasing ZK Touch we received an abundance of feedback from the community which suggested that it is too costly and time consuming to design the UI using a separate component set.

To eliminate this work and the risk associated with it, it was clear that we needed to create components which can automatically adapt and optimize to different devices (responsive components). However, to create said components was a much bigger undertaking than creating a separate component set for our development team. The implementation ended up taking around 6 man months, a far cry from just a week to implement the core components for ZK Touch.

This highlights an interesting point that the work and of supporting different devices still exists, it is just ZK does the work for you and thus eliminates developer risk. So in essence we assume the responsibility of supporting and making sure that your applications can function across many touch devices.

The Heavy Lifting…

A framework should do the heavy lifting for the developer.

A separate component set provides value in the form of a consistent API and UI representation across mobile devices but requires extra time to implement and extra time to style (if custom styling is required).

Having a framework which adapts to a whole manner of touch devices provides a massive amount of value to developers by enabling the writing of an application which will run across multiple platforms with little tweaking. This means that most of the effort can be put on writing the application itself rather than worrying about implementing multiple forms of an application.

Summary

Frameworks should do the work for the developer, by creating two separate component sets some of the work is passed to developers. This in our opinion is totally wrong and contravenes the principle of a framework such as ZK.

If you enjoyed this post, please consider leaving a comment or subscribing to the RSS feed to have future articles delivered to your feed reader.

8 Responses to “Separate Codebase for Mobile, You’re Doing it Wrong”

  1. RichardL says:

    Well said, Tim, and nice work by the ZK team.

  2. dave parker says:

    Please learn about apostrophe’s and they’re use’s.

  3. Thanks Dave, will take your examples on board and make any corrections!

  4. Ron Grimes says:

    Timothy, can you clarify how the framework handles the footprint when changing from desktop to tablet to mobile? For example, is the ZK client engine smaller in mobile versus desktop, say as in the difference between jQuery and jQuery mobile’s footprint?

    Ron

  5. Hey Ron,

    ZK loads JavaScript dynamically so only the required modules are loaded. Additionally the JavaScript code which is sent to the client is handled by the server first, this is to minimize the code size. For example when running on the Desktop the mobile JavaScript will not be sent to the client.

    Tim

  6. Ron Grimes says:

    Excellent! Thanks for the info. What you describe makes me even more impressed with the ZK team. Very smartly designed.

  7. […] To read more on the insight of the birth of ZK 6.5, please visit this blog. […]

Leave a Reply