Feb 24

Feeling Touchy; Learning how to build great touch UI

Mobile, Tech 7 Comments »

As you move to a new platform, it is interesting to watch your brain morph over time. I remember switching from Windows to Mac. At first the fonts looked blurry and weird. The mouse pointer didn’t weight right. The constant app menu was strange. There were things I liked about it right away, but they were mostly the fact that I had a command line, and the fact that apps were minimal, pretty, and useful.

Over time though, I grew to like the Mac more and more. A few months in and it was the Windows fonts that looked too sharp and weird.

I am going through the same experience with webOS and the iPhone. It took me awhile to get used to the back gesture on webOS and not look for a back button. Now I know how to organize my multiple windows, and use universal search as my quicksilver, and so much more. When I open up my iPhone now I am at the point where I try to do a back gesture by mistake. webOS is a touchier, needier device, and as I develop apps and play with the platform, I start to grok that more and more.

Embrace the touch

I discussed touching and horizontal scrolling awhile back, but the more I play with touch devices, the more I find myself wanting to build features for the touch. I have a ton of learning, but here are some of the lessons so far:

Native UI or Immersive UI

One decision that you have to make when you start building your application is the style of UI. Do you want a native looking UI for the given platform?

native-immersive-ui

Everyone jumped on native off the bat. We quickly saw libraries such as iUI come out that let you mimic the iPhone UI. Having a native UI can be important. You want to fit in. However, we have also seen the growth of immersive UIs. Convertbot is the example above on the right. It is task based and you feel like you are really interacting with the app. It is almost tactile.

gmail-nativemail

It is interesting to compare the Gmail and native Mail client UI in webOS. The Gmail version is deployed via a website, whereas the native version is of course an application, but they are very similar. Both use HTML/JS/CSS. Both have their look and feels. Do you try to look like your website (e.g. Google look and feel), or do you try to go fully native. The blending of the two gets interesting. Your brand has to live in another native world.

Haptics and touch feedback

It is usability 101 to make sure that you are always giving users feedback on their actions.

First, how do we signal to users that there are particular touch areas? This one is a bit of an art. We don’t really have :hover and the like. I actually like the idea of having a long press show helpful information, but users aren’t used to using that ability yet (see: need more gestures!).

Where we do have touch areas, we need to make sure to have various depress states for the touch.

Users will touch all over the app, so think about what you can do where.

We are going to see haptics in the future. For now it feels like haptics are used like this:

james-haptics-robot

But the science is coming along. Sony Ericcson has a device (Satio) with haptic support for example:

sony-satio-haptickeyboard

Using the Keyboard: Software or hardware

This brings us to keyboards. What is the optimal input for your application use cases.

keyboards

Feathers by Aral Balkan is a good example of both the task based nature of mobile apps, and custom software input. I like how Aral thought to create an app that solely creates Twitter messages. He didn’t create a full Twitter client that would do it all.

And if you have the pleasure of a hardware keyboard, how can you use that beyond the obvious inputting of text fields. The beauty of a keyboard that come out is that it doesn’t take away space from the screen. Could you offer short cut keys in the app? Different navigation? There is a lot more to explore here.

Gestures. Time to catalog and create new standards

gestures

We are seeing more and more gestures in applications. It feels like we are building out the standards right now. What will be the Ctrl-C’s of mobile? We get to build out invisible ways to navigate.

Tweetie 2 did something interesting when it threw away the refresh button and replaced it with the pull down. Isn’t it more work? Some people don’t like it (Jimmy Fallon for one!) but a lot of people find it more gratifying because it is more natural. We have buttons in the real world, but the apes in us are more used to touching the world around us in very different ways? This is one example of going back to our roots.

shake

Speaking of reload, we are seeing another common gesture here too. Using “shake” to reload, or relayout.

Orientation: Try to accept them, and be more creative

orientation

Have you ever turned your device on its side and not seen anything happen? That frustrates me. At the least, we need to rotate the UI and let it continue. But, can we go beyond that? I have been playing with this. What if landscape brings a more immersive experience?

Take an app that loads a stream (e.g. Facebook, FriendFeed, Twitter, whatever). In landscape, you can view one entry at a time. If the type of entry contains a photo album say, take over the full screen to show the photos and let you flick through.

It really is fun to play with touch apps these days, and I get the feeling that we are still in the dark ages wrt our interaction models.

What patterns have you enjoyed in using and building mobile apps?

Feb 15

Building an Web application from the inside out; Using node.js to bootstrap a server from client JS

JavaScript, Open Source, Tech, webOS No Comments »

Over the winter holiday, Ben and I whipped together Project Appetite, an open source example that consumes the feeds from the Palm application ecosystem (both Palm Catalog and Web distribution). We didn’t have long to come up with something, and one of the interesting stories was how we took an API and mocked up the middle, allowing server and client to get going quickly.

The feeds that the Palm ecosystem puts out are RSS 2.0 XML feeds, with extra catalog-y info in an “ac” namespace. We converted the format to JSON to make life easier for the JavaScript client consumer. Although you can DOMParser() away (and use the Microsoft component) JSON is just so much easier. What lives at api.projectappetite.com is the result of the munging, so others could consume JSON directly if they so wish.

The Data

We quickly put together some dummy data, and for ease, put it in a file app.js that the client could consume. Once we iterated on the format, one of us could go off and write the XML to JSON code. We actually implemented this in a variety of ways as we experimented. Ben created a simple JDOM translation, and I fought with databinding, which still seems to be a royal pain with Java. The reason I checked that out was to create an open backend on app engine, and I wanted to go from XML to JSON to Java for persistence via JDO. From one set of Java objects I could @PersistenceCapable and @XStreamAlias("asset_url"). It wasn’t worth the effort.

The Client

We created an Appetite object that would be able to query the model and get the data that was needed. The constructor took the apps data, and then it did its magic. In this case is created some caches to make querying fast.

The public API contained:

  • app(id, locale): returns a single app based on id
  • find(opts): the core engine for querying the app data
  • types: contained the logic for filtering on top rated, top paid, newest, etc
  • sorts: contained the sorting functions to return the data in the right order (e.g. by download count versus date)

Very quickly the client was mocked up and the frontend was build out using this API. Again, at this point the entire front end could be built without waiting for server infrastructure.

The Server

Since the client API mocked out the functionality needed for the frontend, the server could actually reuse this logic. This is when the node.js server was born.

To play nice with node, we went back to the other files and added logic to export the data. E.g. in the client.js:

// check to see if you are running inside of node.js and export if you are
if (typeof GLOBAL == "object" && typeof GLOBAL['node'] == "object") {
    exports.Appetite = Appetite;
}

Once that was in place, we could load up all of the information that we need:

// -- Load up the libraries
var sys   = require("sys"),
   http   = require("http"),
   posix  = require("posix"),
   apps   = require("./apps").apps,
   client = require("./client");

And then we can get access to the client API via:

var a = new client.Appetite(apps);

We created a simple mapping that enabled a URL such as /app?id=[id]&locale=* to be converted to a method call of app({id:id, locale:locale}). We did this in a generic way that enabled us to add URL endpoints by simply added to the responder hash. The functions would return an object that could contain error codes and the like.

For example, the app end point:

// /app?id=[id]&locale=*
app: function(params) {
    if (!params.id) {
        return {
            error: 501,
            body: 'I need an id!' 
        };
    }
 
    return {
        body: a.app(params.id)
    }
},

We also added a magical DEFAULT handler to take care of bad URLs.

Finally, we would boot up the listening server and handle responses:

// -- Create the HTTP server binding
var host = process.ENV['APPETITE_HOST'] || 'localhost';
var port = process.ENV['APPETITE_PORT'] || 8000;
 
if (process.ARGV.length > 3) { // overwrite with command line args
    port = process.ARGV[3];
}
if (process.ARGV.length > 2) {
    host = process.ARGV[2];
}
 
http.createServer(function(request, response) {
    var path = request.uri.path.substring(1);
    var output;
 
    var responder = (typeof responders[path] == "function") ? responders[path] : responders['DEFAULT'];
    output = responder(request.uri.params);
 
    var contentType = output.contentType || "text/javascript";
 
    if (output.error) {
        response.sendHeader(output.error, { "Content-Type": contentType });
        response.sendBody(output.body);
    } else {
        var body = (contentType == "text/javascript") ? JSON.stringify(output.body) : output.body;
        response.sendHeader(200, { "Content-Type": contentType });
        response.sendBody(body);
    }
    response.finish();
}).listen(port, host);

After 86 verbose, commented code, we had a server that would respond to URLs and return data. And in this time the frontend continued to be built out.

Being able to reuse the client JS and wrap it to become a server was a lot of fun. I am definitely a big node.js fan! Now, I am looking forward to doing a lot more with Project Appetite…. but for now we are working on a pretty cool webOS application, and getting the developer platform better and better.

Some coffee in your Node

In an aside, the node hello world has been ported to CoffeeScript:

# To run, first install node and coffee-script
# Node: http://nodejs.org/#download
# CoffeeScript: http://github.com/jashkenas/coffee-script
#
# In a terminal window:
# $ cd coffee-script
# $ ./bin/node_coffee -r hello_web.coffee
# Tested with Mac OS X 10.5.8, Node 0.1.26, CoffeeScript 0.5.0
 
sys: require "sys"
http: require "http"
 
http.createServer( (req, res) ->
  res.sendHeader 200, {"Content-Type": "text/plain"}
  res.sendBody "Hello, World!"
  res.finish()
).listen 8000
 
sys.puts "Server running at http://127.0.0.1:8000/"
Feb 08

“How exactly do you make your paints?”; What if Google hired artists?

Tech with tags: 5 Comments »

idographics

Ben and I were chatting about interviews after hearing some horror stories from a friend. He made a jape about how bizarre technical interviews can be, and how we often ignore some really important factors… like a portfolio. A portfolio in this case answers the question of “what exactly have you created?”

I will pick on Google as it is the brunt of the “holy crazy interviews batman” trade, which is made more fun now that my sister-in-law is a recruiter there. I like to tease her. She knows that I am a fan of Google and think it is a fantastic place to work. I would be honored to work there again one day for example. Anyway, she doesn’t need my help in hiring… you have all heard about the food ;)

So, feel free to substitute Google for other high tech companies in any story below.

Imagine if Google interviews painters or artists in the same way that they hired engineers. Michaelangelo would show up, and would be hammered on questions about how he exactly makes and mixes his paints. Why does he use that particular kind? Why do those mixes chemically end up with the result that he desires. “If you were on a dessert island with 3 paints, what would they be and why?”, “Discuss the difference between RGB and CYMK”.

This may feel strange. A natural first step when you talk to an artist to see if they are any good is…. see what they have done! “Can I take a look at some of your pieces?” The artist will then probably show a variety that show a broad range of abilities. Some of you have probably had this experience hiring a wedding photographer.

Now, it isn’t that the process doesn’t matter. You want to chat about that side of things too. The right paint may result in a longer lasting piece. The right technique may result in you not getting annoyed by the photographer at your wedding. But, it is probably secondary to seeing what the person has actually done.

Google of course does a fair amount with art. The Doodles for example…. they have competitions for those, and the tools used may or may not play a factor.

Now, you may argue that the portfolio focus makes much more sense for art than other genres, including programming. You can tell a lot from seeing that art, and it is pretty static in time. Programming though, has to be maintained. It has to live. The “how” matters so much more. Maybe it is more like architecture than art. An architect can be known for his amazing looks, or building experiences, but the building better be structurally sound. You would still look at the portfolio of an architect first though, versus peppering them on structural engineering questions.

You do need to test the portfolio. It is one thing seeing that Bob Harris created an amazing website, a top 10 iPhone app, and contributed to a popular open source project…. but what exactly was the contribution. Projects have many folks involved. This is why you need to test the interviewee. Write some code with them. Talk through a real problem that they would actually have to solve on the job (shock horror). Do you *really* think that they will be implementing bubble sort on the job?

Interviewing itself is an art. It is hard to quickly make a decision on if someone will be a fit. Not only does there have to be a technical match in expectations, but there is the social match that is oh so important when a person joins a collective :) I have already talked about how the current process of hiring is like a shotgun marriage and broken but I definitely feel that in a constrained world there are three things that I favour when interviewing a candidate:

  • Understand their portfolio (ask the candidate to come ready)
  • Test the candidate to make sure they match with their portfolio (work with them on what they will be doing. E.g. pair on code)
  • Talk to key people who know the candidate and learn from them about the person
Feb 01

Google isn’t Evil. Flash isn’t Dead; Thank god the Open Web doesn’t have a single vendor

Adobe, Apple, Google, Tech 25 Comments »

openclosed

Steve Jobs didn’t hold back when talking about Google and Adobe. That is great. Life is so much more fun when people speak their mind. I remember hearing a story when Sir Steve was asked why mac keyboards where the way they were. He grabbed a PC keyboard and started to rip out “stupid keys” (print screen, F keys, and the like) and swore a lot.

We love to paint with broad black and white brushes these days don’t we? Whenever I hear people talking about Google being “evil” or not…. I sit back and think about how interesting it is that companies become “people”, especially in this country.

It makes sense when you look up Corporation:

Corporations are recognized by the law to have rights and responsibilities like actual people.

That may have been a convenient (and often almost genius) abstraction by lawyers, but it is screwed up. It feels like the times when you use inheritence in a way that isn’t a ISA relationship, but it does kinda make the code nice. We have all done that, until we learned to favor composition. Corporations ISA Person? No. They are composed of them though.

I have been thinking about this ever since the recently surprise court decision the other day that “allows corporations and unions to pour unprecedented amounts of money into elections.”

Lawrence Lessig had some interesting commentary:

The court decision does feel totally wonky to me. Right now, $ has a direct bearing on elections, and allowing multi-nationals (who have the money) to rain it down makes no sense.

Fun aside

My renaissance friend Graham Glass talks about how corporations can be considered a single conscious in his series on “the mind”.

The issue with the vast number of corporations is that they are profit driven entities whose charter is to bring financial reward to shareholders. While you could argue that we as a species are driven by the selfish gene, corporations are driven by profits. Duh. Capitalism.

Google is a company. It is driven by this same goal. Now, there are various paths to a particular goal to make profits. Some companies sell things that kill people (weapons, cigarettes, etc). Others offer medical devices. All companies are not equal. Having spent time at Google, I do feel like the place isn’t just an evil cult. The people that make up the consciousness were very driven strong willed people that cared about the company mission (universal access to information and all that) more than just the $. Sure some folks are focused on that. Also, although the wool could be placed over your eyes, the guys at the top of the chain have their hearts in the right place. While Larry and Sergey are there, decisions will be made that aren’t solely based on profit. They want to create a different kind of legacy and company.

That being said, I think it is quite easy to fall into a trap such as:

If we do something here to block competition, we can make more $ and since we are Good Guys we can do better things with that money!

Google will sometimes do things that could be considered “evil” by some. That is life.

The good news with Google is that their search and ads business deals in a trust economy. It doesn’t take much to switch from Google to Bing. Google knows that. Even though they have some HUGE advantages (technical [data centers, talent], brand, etc) the low barrier to change is huge.

Not all corporations are profit driven

I had the huge pleasure of working for Mozilla, which is a mission based corporation. Wow does that make life different. While you have to sustain yourself, it does mean that you think of the world very differently. You would rather go out in a blaze of glory doing something great for the mission, than just slowly die not doing much. Every choice you make …. you think of the mission.

It was interesting to work there knowing that I actually wouldn’t want Firefox to be a 90% browser. You can fall into the similar trap as above and think:

We are mission based! If we had that domination we would use it for good!

But, not having that power in one hand is even better. Imagine working somewhere thinking “in my wildest dreams, the market would be shared somewhat evenly with the competition.” The Open Web is amazing in that there is NO SINGLE VENDOR. If we are able to keep a decent balance between browsers (and thus the platform as we know it) then we have a balance of powers. Sure, in some ways you can’t move as fast as a dictatorship, but there is a reason we don’t want dictatorships in our government (even if the trains run on time!)

And, this brings me to the Adobe half of the Steve Jobs equation. Flash isn’t dead. HTML5 is slowly going to put a dent into it if we ever get some of the use cases just right (e.g. video), but Adobe has a good penetration and can move at the speed of a dictatorship. The iPhone/iPad combo not shipping Flash will have an interesting dynamic here too, hopefully helping the HTML5 video cause. There is still much more work to be done. Flash and browser plugins have had a long history at forging new paths, and the Web can come in behind them and standardize. May that continue.

I do watch for single-owned platforms such as Flash, Silverlight, or now the Apple platform (even though they do great work on the HTML5 side of the house). I don’t want any of those vendors to have too much power. The thought of a Web that required the use of their technology makes me shudder (we have a piece of that with Flash video). Right now I can turn off those plugins and life moves on. Sure I can’t Hulu or Netflix, but that will change. I would miss some of the Flash sites that my kids use, but they could even be partially ported over to HTML5 these days.

I don’t want to “kill” these other platforms as they offer competition and spur on the industry. I just don’t want any one of them to take over. It may seem like the world would be better if we all just used Macs and iPhones and iPads, but would it? Do you think Steve would be a benevolent dictator?

Erm, no.

And thus I find myself torn. I really want to go out and by that iPad……. but when is it “too late”. Surely I have a few years right? I can enjoy the shiny new toy? :)