Archives for December 2012

Wired had a piece on GitHub robots and how the company doesn’t seem to be a fan. I was reading and reading to see what the reason was, and it came down too:

“I don’t want to see 100 of these tomorrow. That’s the fear. We don’t want to be the platform where you don’t want to run a project because you’re going to be accosted by so much of this activity.” — Brian Doll

That doesn’t seem to be too strong, and there is room for wiggle room. As we look at the “Internet of things” era, and how “social coding” opens so much up, especially with pull requests as a mechanism for systems to say “I think this may help, take it or leave it!”

ImageOptimiser is one good option. Imagine how many bits are wasted on the Internet due to sending large images? On my team I have an amazingly anal (in a good way) developer who wields ImageOptim and friends to great effect.

It is the tip of the iceberg on what can be done. The dream of automatic bug fixing, automatic performance optimizations, and friends are coming.

I understand why GitHub is wary, and how easy it can be too annoying.

What if we had a robots.txt for Git?

Instead of banning everything, how about coming up with a standard that would allow project owners to define how they want to deal with bots?

We could have a robots.txt^H^H^Hjson that declares how we feel about bots. It could contain info such as:

– bot user agent white list

– bot user agent black list

– limit which branches the bot should look at

If we embraced bots, and built support for them, what could we do?

– a way for bots to register for updates and be called back when changes are made (GitHub has good support for things like this)

– a way to separate pull requests that are from a bot, so the UI itself could show them off to the corner. This is a general feature that would be nice to be able to say “show me pull requests from a whitelist of users first”… priority inbox-esque

– Bots could ask GitHub itself which projects would like it to run (whitelist first) rather than scanning projects. Part of this would mean that the bot could say “show me projects that have images”, “show me projects that use Django”, etc.

What do you think? Should we embrace the bots? My answer is yes.

It has been really interesting to see Google do such a great job with its iOS applications recently. Many have been surprised to see this, as they compare the basic white bland UI from some of the Google web applications.

I am not quite as surprised as I met the Mac team back in the day and they were stellar. They were hard core Mac heads (e.g. the guy who ran the group created MacFUSE, and the creator of Quicksilver was a designer on the team!) who knew their stuff.

I enjoy small UX decisions that bring that one feature that makes you smile, and many of the Google iOS apps have brought over one of these features from the world of Android. The feature is part of type ahead.

I wonder if you have ever had this frustration. You are getting type ahead results (e.g. see the first screen shot of Mobile Safari) and you don’t want to tap on one of the items in the type ahead results list as they aren’t quite right…. but they are close and you just want to edit one. Argh!

Now look at how Google has brought over the “pointing to the top left” arrow in both of the other screenshots above (Google Chrome for iOS search, and a Google search in the browser itself). That arrow is telling you “I won’t act on this term, but instead will shove the contents up there in the text box” which means you can get to refining it right away.

A small feature. But one that takes away that moment of frustration.

All talk and no action. With religious arguments such as “native vs. web” come about there is often way too much talk compared to little action.

I discussed the flawed view back at the time, and one of the things that frustrated Web developers was the flawed argument:

Facebook’s native app is better, therefore native is better

Facebook’s web app was awful. Millions of WebViews. Crappy backends that always return bad information (e.g. the number of notifications is always out of date). The architecture was poor.

When Zuck gets on stage and says that HTML5 was a mistake, people listen though, and it isn’t enough to come out and speak back.

This is why I am so excited that Sencha hasn’t come back via talk, but by action. Please checkout “The making of Fastbook: An HTML5 love story”, which will go through technical details on how they managed to pull off a great demonstrating of rewriting the Facebook app on their Sencha Touch Web framework. Go and save the Web app to your home screen and run it now, and I think you will be impressed.

Are all of the details there? No. They put this together in short order. You can nit pick on items such as not implementing features such as “throw the photo to go back to the news feed”. However, I showed this to someone over the weekend and they had no idea that it wasn’t the main Facebook app.

Is it as fast? It doesn’t matter. We shouldn’t all flip to the “we should use HTML5 for everything!” side of the fence on the back of this, but it should add the nuance that is deserved.

You should be asking about your own application. Do you need the power of native? Do you only need that power in certain places? Do you value being able to update the experience at any time (and being able to easily A/B test and [insert all of the Web advantages])?

This isn’t a game of Web vs. native. It is about using the best of both worlds and making the right trade offs for your users and experiences.

I have to admit that the Web side has been a lil lacking in great examples of what it can do in mobile apps. Sencha has added to the mix here, and a more interesting conversation can happen. Time for more of us to “shut up and code” and share great experiences and how we built them.