How does it do a date picker widget?

Python folks love frameworks. They put framework in your framework so that you can create a framework. A friend of mine was involved yet another of these framework ventures and was seriously excited when he was trying to explain to me how good the new web framework was and what problems it solves.

This blog post is a long flow of mind try to pinpoint how to define if a framework is helpful for you or not. Though I use a Python framework as an example these thoughts can be applied for any programming language, framework, CMS, etc. out there. I’d be especially interest how Joomla!, Drupal etc. popular PHP platforms solve problems mentioned here.

The framework in the discussion was towards high level of web development, contentish things. To make tailored CMS, and stuff. This framework was on higher level than Pyramid, little bit higher than Django. It is named after an egyptian god and because Egyptian gods have difficult names spelled with symbols, my Finnish mind already lost it.

So the friend of mine was trying to convince me about the need and superiority of this new frame and asked the question: “Do you like it?”

And I answered: “Does it help me to get my work done?”

My question was the right question, but wrong in so many ways. We were discussing about the same thing, but from different viewpoints…. and in this point, the discussion got off the rail. My friend tried to justify the existence of the new framework and I was trying to help him understand what kind of needs I hope a framework would solve for me.

As we put a lot of energy in seemingly fruitless conversation, I become sad. This discussion and thoughts about it keep me awake during the night and I tried to come up a simple way to measure the usefulness of a high level web framework.

Now I have a new question, which in the end is the same question as above, but more communicative. This question was inspired by Douglas Crockford’s talk about Javascript metaperformance and especially the part where he tells that there are a lot of smart people doing web – sometimes they focus on wrong things, but  if you give them a proper target to shoot at they can get amazing things done.

Next time, when someones needs my opinion about a web framework, I’ll ask “How does it do a date picker widget?”

Modern Times

To see how my little question works you need to dive into the history of web development a bit.  The web user interaction is much about forms. The forms have input fields and these input fields are wrapped into user interact-able widgets which have additional properties besides simply handling punching of keyboard keys: input validation, typing auto completion, mouse interaction, nice bling bling decoration and effects  and so on… especially when creating things like CMS where the users are expected to input stuff through the browser you need to pay careful attention for the user interaction details.

The purpose of a software development framework is to make the life of a software developer simple and get the thing done.  Because web is much about forms a lot of effort has been put to make form development simple. My question could have been a less form specific; I chose a date picker because it is familiar and everyone has come across one e.g. when booking flight tickets. Thus we should have quite unified idea what we are discussing about. The date picker also tends to be one of the most complex form widgets available in your toolbox, so were are not setting the bar too low here.

Last Tango in Paris

Web itself was not originally designed to have or to do rich widgets for easy user interaction. We have a HTML mark-up language which tries to separate content from the presentation. We have a layout language, CSS,  which tries to separate layout from the content, but in the end fails doing so. Then we have a Javascript programming language which pulls strings in your web browser to make HTML and CSS co-operate and  do the widgets using Document Object Model. A model, which was not designed Javascript programing language in mind.

(sidenote: on the day I see bbc.co.uk level site delivering both web and mobile version from the same HTML code  just using different CSS stylesheets I can say that CSS actually delivers it promise to separate the layout from the content)

Now is now and web is steering more and more to the direction where it can do more for the user… or the interaction is more efficient because of richer controls and paradigms, enabled by Javascript and HTML5, can be applied to solve the same old problems. In this world if you do a modern web framework for and expect it to remain on the isolation on the server-side from all the gory details of Javascript and CSS you are doing it wrong.

Doing a web widget is like a dance of several participants who need to co-ordinate their actions so that the individual performances are in harmony and the actors are not stepping on each other toes. A web framework is like premade step guide telling you how to execute your dance. The result is magnificent performance of  0.5 seconds of your site visitor time when he or she subconsciously picks a date in the web form by clickety-clicky, or as on the mobile era, by thumbity-thumbly.

Missing in Action

Now, I could have asked “Does it do a date picker widget?” The answer would probably be “yes”, as of course you can put a date picker widget on every HTML page out there. Then I could asked “how?” and then the answer would be something like:

  • Download your favorite Javascript widget library (e.g. JQuery UI)
  • Toss CSS files somewhere, Javascript files somewhere in your project
  • Edit your  main template <head> to have these files included – if you are smart include them only on the pages where the user interaction is actually needed
  • Bootstrap <input> fields doing date picking using a CSS class markers or similar markers in the source code somewhere, or have a bootstrap JS running by <input> ids
  • Convert between Javascript widget framework date model and your web framework date model in somewhere of the form layers
  • etc. etc.

This is what I call a blunt approach. It’s solving the problem of dancing like this:

This all is tolerable if you do it once for your web appy. But what about if you need different widgets on the page too? How about checkbox groups with internal dependencies? Time picker?  Yoyo? Again you need to toss files somewhere, edit head, etc.

When your web application grows this all quickly leads to a mess where you have tens of different files included in the main template. Different modules start to clash with their CSS classes and you need to start resolving the issues by your own hand written CSS overrides. Suddenly the page load times are through the roof, because you are doing too many HTTP requests per page. You need to start thinking about the cache. You need to think about merging static media files. Which leads you to think solving dependency orders between media files.

Does the framework help you solve the problems like above to get the thing done?

Notting HIll

I studied industrial engineering and management in University of Oulu (home of IRC – never forget to mention this when I have a chance).  We had a course called Quality which was about quality. You can study subjects like this from very broad perspective especially if your plan is to become a pointy haired boss who doesn’t know crap about what he or she is doing.

The definition of quality is simple. Quality is not the same thing as high value brand (e.g. Mercedes Benz). Quality is not the same thing as faultiness (no bugs in the delivered software). Quality is about whether the customer is satisfied what he or she gets.

The customer of a software framework is a developer. What the developer is buying is a tool to make delivering software more easy – to get the thing done by the end of the day.

My friend was telling how high test coverage the framework has. This is a nice trait for a framework. Higher the test coverage, the less  bugs you are likely to encounter. Essentially this is faultiness.

Now a bad, but thoughtful, analogue: in industrial engineering faultiness comes with a price. On your production line you’ll pay a high cost of 100% faultiness products. You usually want to do testing by sampling and simply let few bad products slip through instead of having the high cost of testing every single manufactured item. In the end, the testing cost of the product is away from the other areas of product development and manufacturing (features, delivery options, etc.)

Faultiness is important, but it does not make high quality software framework alone. Inspired by the leaked rant of Steve Yegge if you dial test coverage 100% but have no accessibility you have no product.

Which brings me to the punch line of software framework quality: accessibility. To enable developers get the thing done with the framework it must have documentation telling how you get the thing done.

Django folks get it. Django has always had very detailed documentation and no surprise it won the most of the hearts of Python developers back in 2006ish when the framework situation was different with Turbogears et. al. being still in their strength.  Anti examples would be packages z3c.form or plone.portlets (chosen by a fair dice roll – guaranteed to be random). Both the packages are frameworkish and have near perfect test coverage. Too bad it seems that only 0.0001% of people are smart enough to use these packages and mostly get frustrated whilst trying to get the thing done.

(sidenote: even though z3c.form has plentiful documentation does not primarily address the needs of the framework users)

Diamonds are forever

Another trait of quality is that it must be measurable.  The absolute measurement of the quality is the customer satisfaction: how happy people are with your product. However the level of satisfaction is difficult to measure directly. Indirect, easy numbers, are measured instead.

One easy quality measurement  is that you go around and ask random users whether they are happy with the framework. If you do not know any of these developers users yet you can simply follow the chat on a related IRC channel:  friendlier atmosphere usually correlates with happiness which correlates with quality.

But being an engineer I hope we could use something more tangible than random chat around a pint or two.

The most important indirect number of your framework quality could be API documentation coverage. How many of the functions of your API have sane helpful documentation or documentation in the first place? As this number  translates to how easily people can pick up your framework and simply read how to get things done with it. Especially with Python a good API documentation (parameters in, results out) is important because Python has poor statistical code analysis or auto-completion support, something  what Java and C# IDEs enjoy.

I Am Legend

The another nice thing you can learn about the quality on the university courses is that less numbers you need express the quality of your product the better. It’s over simplifying of things to say how good or bad your product ultimately is. Your pointy haired boss might be able to process few percent scale numbers a day, but less he needs to think anything besides golf, the better. You suggest a new framework to be used for the new software project and the boss takes a decision if it’s good or not, essentially the boolean value or quality. On the rare day the PHB is on his/her brightest the PHB might think one step forward and ask why the framework is any good and then you can answer that the goodness has been tested with the scientific method found from a random blog in the internets.

.. and to shine at the very end of quality simplification spectrum I came up with the following objective decision tree to measure the quality of a web framework:

Is a web framework, CMS, tool etc. any good for modern development needs? Yes / No

Yes if…

  • You take one average developer, like me, who has wide general programming experience, but not yet insight how the framework works (don’t pick any super smart guy like the framework developer itself might be).
  • You give the developer four hours of time (I am generous about my time today), a hello world style tutorial and API reference manual.
  • The developer is able to create a simple form / content type / page  containing a date picker widget with some customizations like template changes or non-default options. The customizations are important because that’s what you eventually will do – you won’t be mass producing hello world applications from the conveyor belt with the framework.
  • The resulting Javascript and CSS widget bindings to HTML are handled in maintainable manner and media files are merged, compressed and HTTP cache headers are set  properly.

…else no.

This is just a litmus test. It doesn’t necessary tell how good a framework is, but if the test fails then it might be a sign that the framework is either not a developer friendly or is not solving the needs of modern web frameworks. The most possible failure mode is that there are no API documentation at all –  which means that the project is not disciplined to communicate what problems the framework should be solving in the first place and is worth as much as any random bunch of code you can find from the open source archives.

Also, this blog post is just guidelining: no need to nitpick the details unless they advance the humankind somehow. As mentioned before, the blog post tries to give a good target to shoot at and highlights what kind of facts you might need to communicate out to success as a software development framework. Please feel free to challenge me, but as far as I am aware, none of current web frameworks or CMSs passes this test.

Finally, how the proper dance of HTML, CSS and Javascript should look like, Chuck Norris style:

\"\" Subscribe to RSS feed Image Follow me on Twitter Image Follow me on Facebook Image Follow me Google+

Why C# / Javascript will be allowed and Flash won’t be as App Store programming language

All the Flash developers of the world wet their pants on 8th April 2010 when Apple announced that Flash based application won’t be approved in the Apple’s App Store. This essentially destroyed the easy opportunity to monetize existing Flash development skills and the huge Adobe expansion potential into mobile markets, pissing a lot of folks who had bet on Adobe’s technology, leading developers’ rage on Internet forums.  Bad news for those who had already building iPhone apps on Flash CS5 even before it was released…

Unfortunately it was not only Adobe and Flash who got in the line of fire: popular frameworks like Appcelerator, Unity 3D and Monotouch apps are theoretically excluded to enter App Store by the new developer agreement which states that the original source code of the application must be C, C++, Objective-C or WebKit/Javascript.

I belive Apple does not hate certain programming languages. Apple does not either want to force you to use their development tools. Only by understanding what Apple really meant with the infamous 3.3.1  clause in the developer agreement, we can start building a bridge to get MonoTouch et. al. to be Apple’s favorites again.

History of Flash (Lite)

Adobe (Macromedia) and Flash have been into mobile business far before iPhone was published. The thing is called Flash Lite run-time. It runs on billions of phones.

The problem of Flash Lite is that it does not very well integrate with its host environment. It does not even have so simple user interface component as a “menu” out of the box. Which means that every developer must create their own menu implementation. Which means that there exist hundreds of shitty Flash Lite menu implementations out there, each behaving differently and each not resembling the native menu component. This is not a very nice thing if you consider the user experience of the application and iPhone  is all about user experience. Note that this is not so big thing for games, as games have radically different user experience anyway.

Flash does not communicate with its host platform either. You wouldn’t be able to access native API features even if you fully controlled the deployment environment of Flash application, as Flash is a binary blob into which you cannot plug-in more parts. There even exists a product for mobile Flash whose sole purpose is circumvent the limitations of  Flash by using a localhost TCP/IP socket connection and a native server application. If developers choose Flash they choose to lock themselves into Flash and what Adobe gives for them.

This crippling of your platform potential with Flash is not limited to Flash Lite and mobile. I have personal experiences from a project done with Adobe Air for Windows. We wisely chose Adobe Air as a desktop application development platform, because it would guarantee the future portability of our code. However, this nice idea did not really interest in the point when we noticed that we e.g. couldn’t control how File Open dialogs behave (file mask, remember start folder, etc.), severely reducing the user experience of the application.

So, Steve Jobs definitely is on something when he says “intermediary translation or compatibility layer” is bad for your platform.

Note that the same limitation concerns Java ME also. Desktop Java has JNI interface for building extensions, but mobile Java doesn’t.

How other frameworks differ from Flash

Let’s take a MonoTouch for example. MonoTouch is Novell’s open source Mono project based development tool which allows you to create iPhone applications in C# language. Compared to Objective C, development using MonoTouch  has several advantages for certain audience: you don’t need to learn new programming language, C# is closer to traditional Java/C++ languages than Objective-C, you can leverage the full potential of existing C# ecosystem out there, the standard library has more functionality and of course, it is easier to port the core of the application from a platform to another.

Note that the porting part concerns core i.e. application logic only. MonoTouch does not try to separate you from Apple’s platform. It does not reinvent platform services or user interface building blocks, or force something like Windows user interface into your shiny iPhone. In fact, MonoTouch seamlessly integrates with Apple’s platform. You even need to use Apple’s own Interface Builder tool to create user interfaces, which will be exposed to MonoTouch’s C# code. Binding with native API is breeze: below ten lines of code guaranteeing that whenever Apple releases a new platform feature it will be instantly available for all MonoTouch developers.

MonoTouch embraces the platform. You can pick Objective C or C# depending on taste. The resulting source code is similar in idea, different in syntax. There is no “compatibility layer” so to say. Not even technically, as C# is compiled to native ARM binary. There is no way how a person could distinguish a MonoTouch application from an application build using Objective-C.

Open source philosophy and platforms

Appcelerator, PhoneGap and other open source / Javascript frameworks are also protected from Apple’s wrath. They are open source which means that you can tap the full potential Apple’s development platform as long as someones writes a little binding code. Also, they try to use native look and feel and components as much as possible, just to make the applications slick. The frameworks do not have conflicting interest with Apple; the frameworks provide portability to a certain point, but they do this respecting their master.

Flash does not enjoy this freedom; developers can’t change Flash or venture outside Flash’s sandbox.

The Future

There is no point of technically counter App Store’s developer agreement, like saying “hey I’ll just compile all my Flash source code to C so it is C code.” It’s Apple’s game. Apple can do anything they wish and they can also change the developer agreement. So when Apple sees something happening in its ecosystem which might damage it, it simply pulls the rug under your feet again. But Apple can also change the agreement in a positive way. PhoneGap has already went through process of becoming App Store approved framework once. I hope that development communities will not burn its bridges with Apple, but try to communicate this matter with a meaningful manner and come to a development agreement resolution based on ideas given in this blog post. Below is my proposition (IANAL. It is left to the reader to come up with something smarter):

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be written using Apple’s guidelines and best practices to express Apple’s intend how the application should behave.

iPhone is not a monopoly. You are free to build and run your Flash application on a device like N900 on any day and sell it in Nokia’s OVI store. If this is a problem for your business then maybe you should reconsider your business model to be less iPhone centric and promote heterogenicity of mobile platforms and application stores.

Until Flash is fixed so that you can mix-in native code, instead of it being a barrier between the expression and the hosting platform, I find it unlikely any company based their reputation around the user experience would allow Flash on their platform.

\"\" Subscribe to RSS feed Image Follow me on Twitter Image Follow me on Facebook Image Follow me Google+