Linkedin reverting to native app = broken heart

Linkedin had one of the most polish html5 iPad app in the market but they recently decided to kill it off after countless of articles describing HTML5 as a viable solution for mobile. What triggered that 180 on their position? Well contrary to popular believes (that all html5 apps are slow), it’s not speed & animations that made them rollback, but.. memory management. Here’s how Kiran, LinkedIn’s senior director for mobile engineering puts it:

“The primary reason for that is, we’re seeing that more and more people are spending more time in the app, and the app is running out of memory. It’s not performance issues, like speed or rendering, but it’s still a big problem.”
Read more at VentureBeat

Unfortunately they never really explain what tools they use to bake a native apps from their html5 counterpart, so without more informations it’s pretty hard to make anything of this. One unfortunate truth is that dev tools for mobile web apps are in it’s infancy, and there is not quite anything like what native apps can provide.

So with Facebook and LinkedIn quitting the HTML5 boat where does that put us? Well pretty much in limbo, that tells us that most publicly listed companies do not think that HTML5 is ready for primetime and could be associated as a risk for still quite some times.

Looking further

When Zuck rolled back to native, a small company called Sencha decided to push back a little and released a video showing one of their html5 app running against the current native iphone app. Sencha has a framework called Sencha Touch, that is pretty much everything you need to make a mobile web apps that looks native. So let’s check that video:

The Making of Fastbook: An HTML5 Love Story.

Pretty impressive, I personally tested Sencha touch a long time ago and there was a lot of problems on Android, that being said Android versions 3.0 and less were a problem in themselves, the hardware quality was bad and there were lots of bugs and missing implementation in the webkit browser. The situation with Android & Sencha touch seems to have much improved.

Okay, so you are telling me I can make a mobile web app, but other big companies are rolling back but it’s possible but I probably need a big framework to do it?

Well…. not exactly. Like anything else doing an html5 app has advantages & disavantages, and it is sometime appropriate. The principal advantage is you get an app that works on Android, iPhone & Blackberry with minimal efforts with technologies you already know. You made websites when IE6 was around? Well it’s much easier getting something to work on 3 webkit based browsers.

When should I consider doing a mobile web app?

Here a few pointers:

• You have no budget to hire android, ios & blackberry devs but want big market penetration
• You are not reinventing a whole new navigation system full of animations
• Your app is principally text based
• You are still in the prototype stage where you need to iterate quickly

What about CakeMail?

If you looked around this blog recently you probably know hat I am currently working on the first iteration of the CakeMail mobile app. Our current strategy is to release a web version first, iterate a second version (ameliorations) and then integrate this app into PhoneGap and package it for app stores if all goes well.

For that to becomes to fruition I had to build quite a few components for backbone.js that handle different states in the pages(animations, topbar, menu, popin & etc). My plan was to release those components at Js-Montreal this month but life got in the way and I won’t be doing that.

Building a mobile web apps from scratch

It’s not that it is particularly hard, it is just fucking html & javascript in the end, but you definitely need to work out some issues you don’t generally encounter. I probably invested about 80 hours for now in my backbone.js mobile components, and probably need to invest a bit more to make then really solid on ios and android(4.0+).

Why not use jQuery mobile or Sencha? Well I don’t like to stand on top of the next guy, not really understanding what’s happening in the background. Plus the Cake app is pretty small & I did not see the advantage, specially performance wise, of using a big framework. One interesting thing with backbone is that you can really “bend it” any way you want and it’s something I appreciate a lot, my components try to follow the same philosophy.

I plan to do a presentation (probably next month) at js-montreal, if your interested at getting started in mobile web development and you don’t want to be dependant of Sencha or jQuery , you should difinately check that out, I got tons of tips & tricks. Here a small taste of my very unfinished slides:

Turns out, about 3 years ago I asked myself the same question. How can I effectively present mockups for mobile beside just trowing them in basecamp or powerpoint. So I prototyped a project to do just that using jQtouch.

A video will probably explain better than words what this is all about, see below.

A live example helps too (better experienced on a phone). CakeMail let me use our first design iteration for the demo, so you have a sneak peak at that too!

The idea was to sell the app but that never concretized, I still think that there would be a market for this, specially with agencies wanting to impress their clients in a presentation. I’m kind of surprised there is nothing like it 3 years later.

Open sourcing

Head to github to download the code.

The code is not exactly pretty (I refactored it a bit, but it still 3 years old), it’s based on a old, modified jqtouch version and an old jquery version, but it works pretty darn well.

Usage

Everything is controlled by an xml that is given at the plugin extentiation, we can say what we want about xml, it’s pretty nice in terms of readability, here an example that creates a complete app:

	<debug mode="true"></debug>
 
	<!-- Your dock icon on the iphone -->
	<dockIcon src="jqtouch.png"></dockIcon>	
	<size width="320px"></size>	
 
	<!-- Your Startup Screen when your presentation is loading -->
	<startupScreen src="loader.jpg"></startupScreen>	
 
	<!--Do you have images for the horizontal mode? -->
	<screenOrientationChange mode="false"></screenOrientationChange>
 
	<!--This is how you include a mockup -->
	<interface id="main" src="cherry/login.png" horizontal="cherry/login.png">
		<!--This is how you include links -->
		<links href="reports" animation="slide" style="top: 387px; left:10px; width: 300px; height: 50px;"></links>
	</interface>

In that mindset I present today jQuery Engage, a plugin that helps you optimize user interaction with blogs & articles. This plugin adds a social toolbar when the reader finishes reading an article. This toolbar contains customizable zones (comments, subscribe newsletter & share social) that help better convert your readers.

You can test the plugin by scrolling down this page! There is currently 3 content zones on this page. That’s a bit crowded and create quite a lot of noise but that’s customizable and you can have 2 zones instead if you like that better.

The idea

One of the first to incorporate this kind of toolbar was The New York Times. They show a small box at the bottom right of the screen with related content to the article. Not a lot of readers will finish an article and it usually means an interest in the content, at that moment he will likely quit the page or search for more content, the perfect time to show sharing options & related content to keep it interesting.

People are lazy and unfortunately a reader will rarely interact by himself if not pushed a little. That is exactly what this plugin aims at, pushing readers a little.

Make it more personal

jQuery-Engage gives you options to customize the texts depending of the period of the day. Better connecting with a user is one of the tools to optimize your conversion rate, for example talking about coffee in the morning, helps connecting with readers as they take a coffee, that’s the kind of thinking you want.

Highly customizable

The plugin has been created with the idea that there is a lot more content types that could be used in there. The architecture enables you to easily add your own content type into the toolbar. See the github readme for more information on this subject.

The unfortunate ugly

Like when using an infinite scroll the footer is rarely seen by the users. I added an option to close the popup but that is only going to help a bit. Personally, I don’t consider blog footers good converters and I much prefer using my plugin. But nonetheless you should be aware of this limitation.

The future

Related articles, ads, there is much more content types that could be integrated and I hope to add one from time to time.

Do you currently track user behaviours? Most people would say yes, if you have google analytics installed you do track behaviors, at least a form of it. But do you do the extra mile to understand your users? That’s a question that could be really interesting to ask to a room full of product owners.

Let’s take an example of a behavior that most people do not track: a user that made the extra mile and finished reading an article. GA track how much time a user passes on a page, but we never track how much of our users really finish reading articles. Can you do something interesting with that information? Well let’s check what Shopify does.

Acting on behaviors

When a user finishes scrolling through a Shopify’s blog article, the “Subscribe to newsletter” box gets highlighted.

The user is interested by an article and just finished reading it, if he went that far you better give him a hint that he can subscribe to more content easily, so Shopify acts on that. Knowing how long a user stayed on your page is nice, that however does not tell you if he really finished reading your article, logging that data is also useful.

Another interesting situation is a checkout system. When a user puts something into his cart and continues shopping, making the checkout button more prominent is a good idea, reminding the user they already got something to buy. If he quits the website sending a reminder email with the items in its cart is a nice touch too.

Understanding how our users react is essential for the long term longevity of our apps. It’s important to log that information but you also must act on different behaviors. It will help you make smarter apps, giving more context to a user where he normally would miss something, and you are probably going to make more money too.

What about agitated behaviors?

While looking at normal behaviors is good, it’s not as important as knowing when our users become frustrated. When a user is frustrated he is more prone at making harsh decisions like deleting his account or abandoning his current task (shopping, using a wysiwyg & etc).

Do you currently know when and why your users get frustrated? Can you even log such a thing? There are signs that we can track in javascript:

• Does he hit frantically a key?
• Maintains multiple keys at the same time?
• Clicks multiple times on a button?
• Maintain a mouse down a long time on a button?
• Highlight text?

And that’s just a start, there other trackable behaviors too.

Still acting on it is difficult. Deciding if a behavior is serious enough to warrant showing a popover help box, a chat box, or sending an email is hard. In any case, just logging that information helps you understand where your app is maybe failing the users.

Now that you are convince that you must track agitated behaviors, is there even a script that does that currently? Well there is now the jquery plugin below.

A jQuery plugin to mine agitated behaviours

I decided to open source a jQuery plugin I created to help me track those behaviors. You can download it right here.

As the current version (0.1.x) might tell, this is a beta, and it’s never been tested on a big site. So please use with caution. Also, I would really appreciate if you guys add/suggest behaviours into the mix.

Want more?

Please check this awesome presentation on emotional design by Jonathan LeBlanc (Principal Developer Evangelist – PayPal). It covers behaviors and also the color theory.

Another thing is that I wanted easily modifiable generators that could be used in any projects, not just with backbone.

While it’s not really hard to create that kind of functionality with Grunt once you know your way, i”m still pretty new to this and it was my first try at creating a plugin with “advanced” tasks. Still, I am happy to present my last project: grunt-bb-generate.

The idea behind this project is, yes, to provide backbone generators, but my real goal with this project is to have a base for scaffolding projects easily.

Usage Examples

The typical command would be:

  grunt bb_generate:router:name

With the detault options that would generate a router (name.js) in the folder “app/scripts/routers”

Because apps do not always folder standards you can overwrite the path on the fly like this:

  grunt bb_generate:router:name:mypath/to/router

For more information on how to install it, please check the github repo.

Bending it to your will

Just go into the templates folder and add/change the generators to fit your style. After that go into tasks to bb_generate.js and add your new generators. There is a very easy pattern to follow, you should get the gist pretty easily.

The future

The plugin is currently in a very rough state, I am just getting started with grunt and I really want to re-architecture the plugin a bit (contributions are welcome). I also want to add a default app structure. That’s pretty much it for now.

Enter Yeoman, a tool that streamline your front-end development. or so it seems.

Frankly while I now “get” grunt.js and bower, I’m not sure I completely get Yeoman. The idea behind yeoman is to give you the best boilerplate possible to get started with your app development. In some way, yeoman is awesome, from the get go you get a css preprocessor compiler, js compiler, folder watchers, test server and much much more.

But that just how grunt work (pure awesomeness), that’s just one gruntFile.js that you can steal, integrate and modify pretty easily. Other than that Yeoman will enable you to scaffold projects with generators, and that’s where it start to get awkward. Yeoman assume a lot of stuff about how you work (giving you a better workflow as they say), and integrating it in a well under-development project seems impossible or too long to be worth it in my opinion.

My advice? At least have a look at yeoman, maybe it is for you. If it’s not, absolutely save their grunt config somewhere, that is worth a lot of time and money.

I find myself guilty of writing one of those too, my validation engine got from 400 to 2000+ LOC in 3 years. Adding features, one by one, it has becomes overweight, and it has becomes harder and harder to debug.

A long time ago..

Ask me 4 years ago if you should delve into doing a lightbox yourself and I would tell you that you are a fool. Ask me that now? My answer would be a lot more nuanced. Before integrating any 3rd party code I ask myself a couple of questions (roughly in that order):

• Can I code it myself easily?
• Do I have time?
• What browsers is this supporting?
• Number of open issues?
• What’s the code size?
• Do I trust this guy (or team)?

Sometimes I can’t code it myself, I would not code something like Highchart, so I need to use it (or some alternative) & sometimes I just do not have the time. But in my experience, big libraries call for trouble in the long term. You will hit bugs that you will have to deal with, and in that big codebase that’s probably not going to be easy.

How I came to this mentality

Over the years I used multiple big libraries, they all got 2 things in common (mostly), they have multiple bugs & they are hard to debug. Even if you get to debug it, you are now stuck with your version, forget about updates. You can if course create a pull request  to get your fix in, but in most “hobby” libs your pull request will sit there for a long time, and often be rejected for multiple reasons, then you have to make a better pull request or just abandon that.

You also have to consider that you get a lot of dead code, I never use the ajax functionality of my validation engine, but I got that code in every app I make.

An example?

First example, Colorbox, a jQuery plugin that do lightboxes in every ways imaginable. Well all those features have a cost, there is currently 128 open issues on github. Colorbox have 1000 loc & the thing is, a minimal lightbox script it’s about 100 loc. The one I coded for CakeMail does 130 and I’m not even trying to optimize the size, that include options, passing variables and integrating a templating engine. It’s consistent, it’s very small, and it’s easy to build upon if needed by anybody.

Obviously I don’t have all the features Colorbox have, but really, I do not need them.

Let’s take another example, chosen, a very known lib that change your select box into a more friendly usable box. If you go to the chosen github repo you will see that the project is very popular, but you will also see it got 2 versions, one using jQuery and an other using prototype. Most importantly there is about 300 issues and 50 pull requests pending. That’s certainly not extraordinary.

Even better, you can replicate some of chosen features like skinning the select using only some css tricks, and it’s valid up to ie7. Talk about performance enhancements.

An exception, the agency developer

Having work in multiple web agencies I can see how big libraries becomes handy. You work on multiple websites or apps at once, on tight budget & tight delays. Creating a ton of different products makes for a ton of requirements, and that’s where these libraries comes in, you don’t want to code yourself an image sliders in a lightbox, it’s much faster taking one that does everything for you and hope for the best.

Also theoretically, it  makes it easier on the long run for your team to collaborate always using and fixing the same plugins, even if there are big.

The Validation Engine future

Like I said, I am in this boat. I am currently looking at making a much, much lighter version of my validation engine, I want to get back to that swift and more manageable first version of 400 loc. I’m not saying I’m killing the big one of course, it’s just that I am currently lacking a light validator in my day to day work and I want it, badly.

You don’t have to search far to understand why. Using jQuery is the easiest way to add interactions to a website. The api is intuitive, easy to use, the documentation is solid, it works cross-browser & that api very rarely changes.

Or was.

2.0 will be a major rewrite removing support for ie8 and earlier releases, it also removes a bunch of deprecated methods. 1.9 already started the ball removing a lot of stuff in preparation of 2.0, including the live api, and that made a bit of drama. Of course they created tools to make it has painless has possible to migrate but the facts remains, jQuery will change a lot in 2013.

One of the heartbreaker for me is how they now handle HTML strings vs selectors in 1.9. I won’t go in details but here’s how I need to handle underscore templates now because some of my templates start with a space or tab:

$( $.parseHTML( _.template($(“#content”).html(),{})));

A small anecdote

Less than one year ago I had to take a skill test in a major firm in Montreal. In it, some jQuery tidbits, one of those asked me which of these methods I should use in certain conditions, between live(), delegate() and bind(). Nothing on the unified on() method. Trying not to be an ass I added some explications on the on() api instead of the choices I had.

But that made me think about decapreated jQuery methods and the users expectations of support from the jQuery team. Most web devs I know that are not passionate about front-end still have a very good knowledge of jQuery, and most of them expect two things. First is it’s not going to change and secondly it’s compatible cross-browser.

In the end..

The biggest reason why jQuery became popular was that it had an unified way to make work complex solutions on ie6, ie7 & firefox.

We are losing a bit of both those points that the average user expects from jQuery and that makes me feel awkward about the new releases. Not to say jQuery should not move forward, my feeling is probably wrong but it’s still the feeling I got right now.

2011
Year in review

2010
Overtime and web developers

Early 2009 (Predictions & random thoughts)
Where front-end web development will be in 5 years? (Chuckle…)
The next generation of web developers and designers

2008, from my old blog
The front-end developers burden (First article ever)

Less and Sass changed everything again

CSS preprocessor got an hard time at first and lots of devs were against it, myself included. Just thinking about debugging this mess was telling me it would never be worth it. Boy was I wrong. Where CSS standards failed, CSS preprocessor flourished, and it’s now the way CSS should be build. It also helps that big projects like Twitter Bootstrap really jumpstarted popularity and tools to build upon.

Working with Less is just a joy, using mixins feels natural and not adding 3 times border-radius for old browsers is magic. Throw CSS Hat into the mix and you get auto-generating LESS code for Photoshop effects that works.

You will no longer hate your designer and your designer will love you back thinking you are the fucking best front-end developer he never saw in his life (just don’t tell him the trick).

Twitter Bootstrap

In 5 years, looking at old web internal tools much of them we be built on Twitter Bootstrap.

Twitter Bootstrap launched in 2011 but really picked up this year. It’s the perfect boilerplate to any web project, with multiple JS components, perfect CSS & HTML, LESS mixins, all tested on IE8, oh yeah and it looks pretty impressive.

If you have an internal tool to build on a tight budget and you do not use this project you are probably missing out a great opportunity to give a great default UI to your project and improve the general quality so it can last longer.

Web tooling frameworks have multiplied

If I base myself on how earlier technologies have blossomed like JS file loaders, 2013 will be the year of shell tooling frameworks. With Jazy, grunt.js, Yeoman we already got some serious quality projects starting to get some steam.

I took a look at Yeoman and even created a small script to automate my build process in node but I’m not completely ready to jump into the boat yet, pretty sure I will come around in time, like I did for JS file loaders and CSS preprocessor!

Mobile web apps have taken over native, NOT

Yeah, yeah Zuck dumped it’s HTML5 app for a native one, I can’t blame him. Facebook MUST give native performance to their users at the scale they are, that makes sense. But if you got a small product, a small web team, you can really get 95% there with good old CSS3 and HTML5 if your good at it (and if you only support iOS5+ and Android 4+).

Hell Linkedin created an amazing iPad app using HTML5, if it’s not a proof that it’s coming along, I don’t know what is. Their engineering blog is full of information about how they created it too.

Also please check the demo of fastbook from sencha, it’s pretty good.

More and more front-end MVC

With angular.js, ember, spine and backbone.js you got some hot action in the MVC front. I don’t believe detractors that says javascript is not powerful or fast enough to handle a complete stack and says things like it won’t handle big datagrids or won’t cache properly. It’s ready, already a lot of companies likes grooveshark use the front-end stack, and you also got Google investing some big bucks into Angular.

Earlier this year I launched backbonefu.com because we were cruelly missing a place where you could delve in multiple backbone articles (Unfortunately I let that website a bit driftting). Obviously I throwed myself into backbone, and with some good success’s launching WeddingDeck, and currently working on the Cakemail mobile web app and making very good progress. I really like how easy it is to modify the code base to my wish, and it was in fact built in a certain way that allow encourage you to bend it like this. Compare that to angular you need to be a lot more careful if you decide to dabble into its core.

I’m not saying Backbone is better than everything else (because it really doesn’t), angular and ember look pretty awesome but currently I try to stick to what I can work with.

Here we go, that’s what got my attention this year, see you next year!

Uploading in a nutshell:

<form method="POST" id="frm_upload_logo" action="/ui/settings/logo" target="upload_logo_iframe" enctype="multipart/form-data">
 <input type="file" name="logo">
</form>
<iframe src="/blank.html" name="upload_logo_iframe" class="upload_frame"></iframe>
 
<script>
        $("iframe[name='upload_logo_iframe']").load(function(){
            if ($(this).contents()[0].URL.indexOf('/blank.html') == -1)
            {
                // Upload is complete, do something
            }
        });
</script>

So… Html5

Looking for a easy way of implementing desktop drop file upload for CakeMail I was confronted to 2 issues. One, I’m not sure anyone is using drop file uploading beside web developers using Gmail. And also, my current implementation require 0 lines of code & is stable in every browser. Should I even think about implementing a point of failure with a different behaviour in older browsers when I got this solid solution?

Dragging, really?

Trying to look for articles on the usefulness of the drag and drop file api is futile, you will be greeted only by articles talking about implementation in 50 ways possible. Only thing left to do? Asking friends if they ever dragged a file in their browser. The response is overwhelming, 0 ever tried it.

Frankly even me when I do it I don’t find it’s a great experience even if, I agree, that it is sometimes convenient. It always involve bringing my finder window at the forefront, closing the multiple finders I had open, moving the finder so I can see at least a part of the upload box, and finally dragging it in a partially shown box. Not what I would consider a great user experience.

Really not sure this is helping normal users navigating your app, finding that file in their folder in another window also gets them completely out of your app. Personally I think we just like it because we drool at the fact we are dragging files in our web apps and it works, not because it’s really useful.

The Html5 file api

Then there is when you need to upload big files, now you get a bit of trouble with html4 upload. There is no api giving you progress on your upload and that arguably can be pretty useful. But in this day an age, you need to really think what a big file is when most people upload at 300k per seconds I rarely see a use case for that (beside for video and big archived files).

I’m I saying that you should absolutely not implement those api’s? I’m not, if you have time on your hand and want to add some alternative paths in your app great, or if you are uploading big files then you need a progress bar instead of just a gif loader. But I think you should really think about the usefulness of those integration.

In the end you still have to default to HTML4 form uploading for IE users and having 2 implementations for the same functionality always add complexity, testing time and bugs.

Got any articles or paper on uploading files user experience design? Please post them in the comments, I would be more than happy to read them!