Downfall of Code - REMOVED

Due to the fact that the video clip I posted here yesterday might be considered offensive by some people, I decided to remove it.

The intention in creating that clip was for humoristic purposes only.

I sincerely apologize before those who viewed this clip and were offended by it.
This was not my intention.

I would also like to clarify, that just like any other past and future posts made in this blog, the creation and posting of this clip is of my own personal doing and in no way directed nor sponsored by Magic Software Enterprises.

Browser Free RIA – The Best Approach for Enterprise Applications

For many people, the term Rich Internet Application (RIA) is automatically associated with a browser. It is quite understandable how the browser, being the most ubiquitous internet application ever, has become a synonym to the Internet itself, and as such has become the default gateway to any internet based initiative.

Unfortunately, when it comes to real business application, and also complex core business applications, the browser as a front-end facilitator is far from being adequate. The browser, as the name suggests, is intended primarily for browsing and for light data entry that is required for more accurate and pin-pointed browsing. When medium or heavy intricate date entry is required, the boundaries of the browser are becoming more noticeable.

Ajax is great but…

Ajax is an example genuine browser-based UI. Ajax user interface (UI) is on the one hand free of any third-party software other than a browser but on the other hand it is completely dependent on the browser capabilities and usually is designed to meet the lowest common denominator of the various browsers currently available. A recent study done by Forrester Research Inc, titled "Ajax Disappoints Power Users Looking For Web 2.0-Style Business Apps" suggests that though Ajax based UI may serve and satisfy very-infrequent users or occasional users it fails to deliver the expected user experience (UX) for power-users who used the application very frequently.

The Forrester research focuses on the fact that Ajax is mainly script based pattern of development and is very much dependant on server side services. These two facts put together in a UI abundant with data entry and data display controls result in poor performance and consequently poor UX.

Though Ajax developers are able to produce quite nifty UI, it is, in most cases, an attempt to mimic the UX of desktop applications and together with the efforts required to clean-off irrelevant or unsuitable browser functionality (e.g. Backward, History) and replacing existing functionality with an appropriate one (e.g. context menus, pull-down menus) suggests a very complex and tedious application development and later on application maintenance.

Waiting for Outlook to turn RIA

Google's Gmail UI makes a very good example for Ajax based UI and offers a nice UI. However as far as UX goes, I still prefer using Microsoft Outlook. Try opening in Gmail two different emails (conversations) in two different windows. An ability so natural and trivial in a true desktop application is in most cases missing in browser based UI. When the day comes and Gmail will support opening multiple conversations concurrently in independent frames the industry will celebrate it as another giant UI leap achieved over a browser.

Proper windows management in desktop applications

Now don’t get me wrong, I also use Google's Gmail and not just Microsoft Outlook. However I would prefer to use a true desktop UI much like Outlook which, like Gmail, is available from any new machine I might work from without needing to explicitly install and while keeping email folders on the server.

If, as an organization, I need my core business application to work over the Internet and to keep my end-users satisfied and productive with a rich and highly interactive UX I need mainly two things: A dedicated server and a dedicated UI. I do not necessarily need a browser.

Browser Disillusionment

When we started working on uniPaaS and its RIA technology, we noticed that many CIOs and CEO's were still very much fixated on the fact that RIA must be browser-based. Slowly but surely, as we have advanced our RIA technology, we saw how more and more decision makers become disillusioned and understand that a Browser cannot really be Jack-of-all-trade and that there are many challenges that simply do not suit a browser based implementation. Some have reached this disillusionment from a bad browser-based experience and some simply by objectively and sensibly analyzing the merits and faults of each alternative.

To address this growing need Magic Software developed its new RIA technology supported by Magic Software's latest application platform – uniPaaS.

If it looks like a desktop application, and feels like one…

uniPaaS RIA offers organizations and software vendors the ability to provide easy to use and easy to adopt UI that is implicitly installed over the internet and is fully served by a centralized internet server for the means of live data provisioning, data entry and live application updates. The benefits of uniPaaS approach to RIA are many. On the one hand the developers get to produce UI in a form very much similar to the way UI is produced for common Client\Server applications. On the other hand, the end-users get a UX they are familiar with and accustomed to. Together with the rapid application development uniPaaS offers and with the unitary approach for developing partitioned applications such as RIA (where much is to say about this matter separately), producing core business RIA is becoming a trivial task for any Magician.

A sample screen from Magic Software live RIA Demo

I invite you to try Magic Software live RIA demo to get the feel of the UX it has to offer. Most likely you will feel quite at home with a very intuitive and familiar UI –

This is the exact intention.

Double Negative in Checkboxes

If you do not want to not read this post please proceed reading it…
Recently, I keep stumbling on annoying cases in which checkbox controls are designed to activate a negative operation. This is well illustrated in the example below:

Such cases are double negative and are very confusing, especially when the option to be marked is complex by itself.

[BTW, if the recipients I send my email to are working in the same building as I am, and they are running out of office, I guess I should be running out of office too, may be a cubical just caught fire… but I digress.]

Wouldn't it be simpler to have these checkboxes like this:

The problem with negative checkboxes goes beyond mere confusion, but also suggests a negative impression end-users get. Too many "don't do that" give the end-user the impression that the application they are using tends to do too many things which one better turn off.

It seems that such checkboxes where created with the notion that the feature of notifying the sender on "Out-of-Office" recipients is often regarded as a nuisance. Indeed, this way, this checkbox impart that feeling exactly: that this is probably an annoying and a redundant feature.

Here is another example:

It is very important to understand the mental-model of a checkbox: By turning on the checkbox option the end-user turns on ( "Activates") a particular capability. By turning off the checkbox, the end-user turns off and "deactivates" that capability.
"Do not ...." suggests a passive state. There is less sense in activating a passive state.

I must confess that there are a few cases which I am not yet sure if they should be treated as exceptions to the rule, or to be replaced by proper rephrasin of the option text. Two, very common, cases are "Ignore" and "Disable". On the one hand they are kind of a common instructions power-users are already accustomed to, though they suffer from the same problems as regular negative phrases. The Ignore options in this example:


Could have been easily phrased as:

So next time you define checkboxes in your application – THINK PUSITIVE.
(Yeah, I know I have spelling mistake. My "Ignore words in UPPERCASE" option was turned on…).