The Rubin Way

As described in The Pragmatic Programmer: From Journeyman to Master, "Every craftsman starts his or her journey with a basic set of good-quality tools... Tools amplify your talent. The better your tools, and the better you know how to use them, the more productive you can be... Always be on the lookout for better ways of doing things."

Coming from a web development background to the mobile scene and developing in (relatively) new technologies such as Sencha Touch and Phonegap I find that good tools to help you in the job and improve your productivity are far more scarce and much more needed.

Much more needed because, by nature, mobile debugging is more complex and time consuming. You don't have a debug/console browser desktop window available all the time as your application runs in the device (or simulator) and deployment to devices naturally takes more time then running in your browser from a local webserver.

After getting some suggestions from friends and doing some research, I have compiled a list of nice tools and advices that I would be happy to share.

Chrome vs. Safari

Safari was my natural choice as I was initially focusing in Phonegap for iOS. But I have found out the Safari has some limitations. First, it is not updated frequently as Chrome, thus many nice improvements and bug fixes for the Developer Tools are lacking. Second there are less extensions option for Safari. After working with Safari for some time, I now stick with Chrome.

Window Resizer Chrome Plugin

The next step is to have your browser window with the same size of the device. Don't forget to get into account the status bar for specific devices (iOS for example has 20px status bar). Window Resizer Chrome Plugin is a good options for Chrome, but most of the device's resolutions you will need to configure by yourself. Don't forget to choose "Mobile Device" when configuring a new device, so it won't take into account the window size but the browser's viewport size instead. Update: Just found a new plugin - Resolution Test. You can try it also.

Responsive Design - Resize Browser Bookmarklets

The resizer plugin above has some limitations. First (in my Mac) it cannot resize the browser window below 400px - so you won't be able to simulate some phone devices. Second you cannot have different windows sizes at the same time on the same page - this is specially useful in an Android world, where devices probably have different resolutions and you want to test side by side. Some people have created different bookmarklets (which are tiny js program contained in a bookmark) for solve those issues. Most remarkable ones are David Chambers, Been Keen Bookmarklet genereator and Resizer.

Ripple

Another nice tool is Ripple. Although now owned by Blackberry, it is can be used on different platforms to simulate APIs such as Phonegap and you can use standard browser (Developer Tools) to debug the application. Honestly I have used it in the past and I was not happy with its stability - this seems to have improved now. May be worth to use it if you are having issues with Phonegap API and deployment to your simulator or device is a slow process.

xScope mirror

A new tool that was just released is xScope mirror. It is part of xScope app, which is "a powerful set of tools that are ideal for measuring, inspecting and testing on-screen graphics and layout". xScope Mirror basically let you mirror a browser desktop window in your iOS device over the network. I don't think you would buy xScope only because of the mirror feature, but the app itself is very recommended for designer and developers - it is really worth 20 bucks (now in sale at AppStore).

Weinre

Weinre is a very nice server-side solution to web inspect and run js code remotely on devices and simulators. Its UI is very similar to the Webkit's Developer Tools. I consider Weinre the tool that provides the most realistic inspecting/debug capabilities, as you can use it in real running mobile apps. Together with that, it has some drawbacks - first one is that you cannot really debug (like using breakpoints and so on) but only inspect elements and run code in the console; second is that it tends to mess with complex Sencha applications, so in some situations you just cannot use it.

BlackBerry's WebWorks Web Inspector

I'm not a fan of BlackBerry, but for those of you who are using Blackberry 7 devices such as Playbook I recommend taking a look at Web Inspector. It could be a good option in addition to Weinre.

Tools are very important in order to improve your productivity, specially in the mobile scene, where there are so many different platforms and devices.

Hope the list above will help you - I will be happy to get more tools sugestions and reviews in below comments.

I believe that one of the most important personal traits is the ability to analyze past actions or decisions and be able to regret (and also to decide and make a change). I think that this is true regarding personal life and also professional decisions.

One of the things I have regretted lately, in a project my team has been developing, is the way we have handled references. The project is basically a dashboard project, something similar to iGoogle and NetVibes, but for enterprise usage. (oh God, I hate the "enterprise" word!)

Technically speaking, the dashboard, which has client side developed in javascript using jQuery and jQuery UI, can contain several widgets with relevant content applications rendered using OpenSocial standard. Those widgets are grouped in pages and can be resized or dragged in order to obtain flexible layouts.

Javascript speaking, the application is divided into modules (i.e. namespaces). As an example, a module take care of loading pages from server and respective callbacks; other is responsible for rendering the layout of the pages; other module renders content and events for the gallery of available applications; another is responsible for the welcome screen, which are guidance messages for new users on empty pages. Many other modules have different functions across the application.

Let's drill down with an example so you can understand the problem. As said before, our dashboard can have pages (organized in tabs) and those pages are lazy loaded - when user selects the tab, the page content is requested from server and loaded using an AJAX call. Let's say that we want, when a page is loaded, that:

• The pages tab should be resized so the name of the current page is fully displayed
• The layout for the current page should be rendered
• A welcome message will be presented if page is empty
• The gallery of applications should be closed if it is open
• A new user's guide tooltip should be attached to the page's widgets now loaded

So our first implementation was to call all those different modules directly from the success callback of the AJAX for loading the page:

      
// Callback after loading page from AJAX                  
goToPageCallback : function(opts) {
    if (Ews.WorkspaceManager.pageWasLoadedByAJAX(opts)) {
        var parsedData = jQuery.parseJSON(opts.data),
        // New Page being loaded from server's JSON
        newPage    = new Page(parsedData);
    }
    // Pages tab should be resized so current page name is fully displayed
    Portal.html.tabsHover();    

    //.... some code

    //Collapse gallery if it's opened
    if (Portal.gallery.isOpen()){
        Portal.gallery.hide();
    }    

    // ... some code
    // Render page layout
    Ews.WorkspaceManager.currentPage().layout.controller.renderLayout({},opts.pageId);

    // ... some code

    // Enforce guide is displayed if new page was loaded by AJAX
    if(Ews.WorkspaceManager.pageWasLoadedByAJAX(opts)) {
        Portal.guide.onPageChanged(opts.pageId);
    }

    // If page is empty, display page initialization screen
    if(Portal.dom.getData('widgets').length == 0) {
        Portal.welcome.pageInit();
    }
}

What's the problem with the code above ?

From my experience, the main problem is that you are creating hard references between namespaces in your application, or in other words, you have a high coupled application with many decentralized coupling junctions. Why a module that is responsible for the loading of a page should know about the existence of a gallery or a welcome screen? This is conceptually very bad, you have a high coupling between parts of your application which turns to be a nightmare for maintenance and future development.

This leads also for many bugs, specially regarding DOM elements animation. Let's say that the render layout call renders the different widgets in the current page using an animation. It is possible that when the render guide call (which needs to act on widgets already rendered) starts executing, the layout rendering is still not finished placing DOM elements in the correct places because of the animation, thus the render guide fails (or works badly). The worst thing is that because of the nature of javascript (one thread), this may happen or not depending of the computer and browser speed. A nightmare !

How do we solve that ? Observer Pattern. Use events instead of hard references. We can create a "post office" event service, which will be responsible to centralize all the coupling across the application. In the example above, after the page was loaded, we would trigger a "page.loaded.finish" event and all the other modules, which have subscribed previously to this event would execute callbacks inside their own modules. Simple, centralized and clean.

Apart from avoiding coupling, this event service could have also many other useful features, such as:

• Know beforehand all the events supported, thus if someone subscribe (by mistake) to an undefined event, it raises an exception
• Unsubscribe from an event
• Help debugging by providing a debug console
• Pass, together with the event data, the originator of the event, so subscribers can ignore it depending on whom has initiated it
• Pass publishing time of the event
• Asynchronous & Synchronous callbacks : The subscribers will be called one after the other or together asynchronously. We could use jQuery Deferred Objects feature for implementing this
• A subscriber blocks other execution, so we won't have DOM animation issues
• A subscriber can cancel the event, thus event will not bubble to other subsequent subscribers
• Raise exceptions on callback errors in a clear manner
• A subscriber callback is only executed after the event occurs n times
• We can add constraints/filters for events above subscribers

Many other major js frameworks already implemented this pattern and it is a very common pattern in a client side application.

For jQuery, because of its simplicity nature, the standard way for implementing this functionality is by using the trigger and bind functions for custom events. It is very simple and does not provide many of the functionalities of major frameworks. I have found only one serious jQuery plugin implementing some of the features described above. I did not use it in production - if you have some experience about any jQuery observer plugins please drop a comment below.

So, in this big blog article, we saw the problem with hard references and how to avoid them by using the Observer pattern. I have also proposed a possible event service implementation - What a good suggestion for a pet project !

Yesterday I had the pleasure to attend my first session of the Lean Startup Israel group. By definition, the Lean Startup group "focus on the business aspects of startup and the various implications". In this session, Tomer Sharon, UX Researcher at Google US, was invited to discuss and answer questions on different UX topics in a forum mediated by Guy Nirpaz, co-founder and CEO at Totango.

Although I'm (still) not a startup founder, I have become more and more interested in UX topics lately, mainly because my work as a front end developer. It took place at Outbrain's office in Netanya, Israel. People that attended the session were mainly founders and co-founders of different startups and the topics discussed there were very interesting, even from a developer perspective. I will try summarize below the main subjects of the session.

Tomer started the session by showing us a funny video (still do not have the link, sorry) about usability tests in Google. After that, he talked about different topics:

• What is User eXperience ? There are many definitions, and UX is not a new topic. It does not relies only on software, UX can affect everything, from computers to clothes.

• The first advice for good UX: "Get out of the building" by Steve Blank , i.e., it is very important that you go to the field and understand your users

• Understand your users does not mean to ask them what they would do; actually it is proved that most of the time they will do the opposite of what they say. You have to see them in action - do not ask them directly.

• If the only way available to you is to ask users, then your approach should be to inquiry them about some bad experience from the near past.

• Regarding Usability tests...

  Tomer stated that they are the key element for improving UX. Watch users working. Try to understand user actions alone - but you can also ask them to explain.

  It can be done earlier or later in a product development. It does not need to be done using real software, it can be done using a mockup, powerpoint or even paper and pencil.

  It can be done once a week in order to improve your product flow continuously. It can also be done for a simple flow or concept. Ask users to think aloud.

  It does not need to be promoted by UX experts, it can be done by anybody, although Tomer does not recommend that developers test their own baby project. It is important that real users will do the test. Also sites as usertesting.com are problematic, as it turns out that testers become professional UX testers and do not reflect the real user behavior.

• Do not fool yourself: the improvement of the UX never ends. It is a continuous process, where it is almost impossible to figure out and fix all issues, but still it is very important to identify and fix the main ones.

• How does google improves UX ? By using many usability test technics, such as online tests (which cost a lot of money) and instrumentation of user behavior on existing applications.

• There are hundreds of metrics for good web UX. Tomer talked about first click, bounce rate and others.

• Good UX does not rely only on UX Researchers: it is also relies on good design, good technologic decisions, good product management and many other factors.

Finally, Tomer recommended four (thin!) books for UX improvement - those books are a good match for all types of people, from developers to founders:

• 100 Things Every Designer Needs to Know About People by Susan Weinschenk
• Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems by Steve Krug
• Simple and Usable Web, Mobile, and Interaction Design by Giles Colborne
• Undercover User Experience Design by Cennydd Bowles and James Box

That's it ! The session was very valuable, I would like to thank the Lean Startup guys and Tomer Sharon for the great opportunity.

The session was recorded, so I will update this blog whenever the video becomes available. I will be looking forward to read the recommended books and I hope to keep this blog updated with future UX opportunities such as yesterday's.