But to my surprise, they have released an open source data store, dubbed “Sensei DB” which I find really interesting. (They may in fact have released it a while ago, but I just recently have discovered it)

• It’s built for high reliability, fault tolerance and scalability
• The main uses are for full text search, key value store and realtime updates
• It includes a new query language, very similar to SQL, which they call BQL, or “Browse Query Language”

All in all it looks pretty interesting.

More information about SenseiDB on its website: http://linkedin.github.com/sensei/

I wanted to write up a summary of my experience using the device.

I’m not going to bore anybody with specs, information or detail. Enough information can be found online, eg. on the Amazon Kindle store.

First impressions

My first impression and experience of using the Kindle Fire was actually pretty good. I had read some reviews and was prepared for the worst, but actually the whole experience was quite pleasant.

I turned it on, logged in with my Amazon account (I am an Amazon Prime member) and immediately I saw my Kindle books there, which was nice.

Playing movies

The first thing I tried doing was playing movies and TV shows. The search is great and navigation is very understandable. Streaming a movie is super fast and nice and there were no hickups. I watched a Star Trek episode and started playing some movies and it was just great. The image quality is very adequate for watching a movie or a show, the volume is nice, so for watching movies or TV shows there’s not much negative to say about that.

If you’re not an Amazon Prime member, I can imagine that buying a TV show for a few bucks can be a bit annoying, but Prime is totally worth it, so you should just get a Prime membership if you’re going to get one of these devices.

Reading books, pdfs

Reading books works just as well as on the normal Kindle. It’s not as nice to actually read for a long period of time, but I don’t really want to use this device to read anyways.

However I hoped that reading PDFs would be nice, but it actually isn’t. It could be but the only problem is that navigating a document is kind of a pain, especially since when you start dragging, the anti-aliasing of the text goes off. So the text flickers while you do that, and that’s highly distracting.

That was probably my biggest disappointment.

Playing games

I’ve been playing angry birds (of course) and Cut the rope and both those games are super smooth. The touch screen works well and the graphics are very smooth. This is a great device for playing android games.

Apps and the Android market

The app store on the Kindle is a bit of a let down. I think it would be nice to have access to the real Google market, since there aren’t that many apps available. For instance the Twitter app you can get is just a shortcut for opening the Twitter mobile site. That sucks.

But there is some selection of apps, but it could be much better.

The UI

The user interface seems a bit lame. It probably looks good to a lot of people, but I just feel that there’s too much chrome and fancy animations all over the place. And not the kind that makes the usability better.

Searching is really strange thing on the device. Mostly because there’s a lot of search bars all over the place and they don’t search the same thing. It’s easy to get confused and not realizing where exactly you are searching, so that can definitely be improved.

Your personalized app list is kind of lame as well. You get this cover flow-type of UI for browsing the apps and your books (all intermingled, which I don’t know what I feel about yet) and there’s a secondary view that views them all in a row. It’s just a bit strange and arbitrary and I wish they had gone with a more traditional UI for that stuff.

Those are definitely obsessions and I bet most people won’t care at all about that and the UI will work just fine.

The hardware

The Kindle Fire is a bit heavy compared to an ipad, but you get used to it pretty quickly. The battery life is fine, and actually exceeded my expectations. You can watch a couple of movies and play a game on the device before you deplete the battery.

Other than that there’s not much to say about the hardware. The only issue I found is that it’s a bit finniky to plug the USB cable charger into the device, but you get used to it.

Conclusion

I can’t help but recommend this device to people. Especially if you just want to try having some secondary device to lounge around in your sofa for a few hours a week. It works well for what it does, and that’s about it.

At first I was like “It’s going to become the most used framework evar!” But then I thought about it a bit more and realized that this might not be the case.

How does a framework or a language become popular?

One way to think about how a new programming language or a framework becomes popular is examine what needs to be in place.

• A vibrant active community.
• Good libraries and/or a healthy amount of contributors of libraries
• The use case for the language / framework must be clear
• It must be easy to get into, to learn.
• Easy to set up and get up and running

To me Node.js checks all the boxes on those, and it seems to have a lot of tailwind blowing its way.

The usability and barrier to entry

Another way to think about languages and frameworks is what the user experience for a beginner to intermediate developer is when starting their first steps trying out the language. How hard is it to get up and running with something simple? How useful is the default stack? On how many platforms is the framework/language available on?

To me, getting up and running with Node was super super easy. There’s plenty of examples out there and there are interesting frameworks like Express that do all the heavy lifting for you.

There’s also a plethora of Javascript developers already out there who are already building stuff in Javascript (although sometimes they might be referred to as “jQuery developers”), so they already are familiar with the language and the evented paradigm.

Will Node become ubiquitous?

In my mind I think it will. I’m also a bit afraid that Node.js will become the next PHP. Is that bad? I don’t know. PHP gets a lot of crap usually, but when you think about it, it does one thing really well: It’s super easy to get up and running in PHP so the barrier to entry is low. It really is perfect for beginner developers.

Node.js doesn’t have the same ease of use, but imo it’s better than Ruby on Rails (although people are free to argue about that)

Conclusion

It’s code year. Get on the horse and start coding. I don’t care what language or what “stack” you choose and ultimately it doesn’t matter. But if you want to choose Javascript, I can’t blame you.

Node is the future.

And when I’m brainstorming, I might come up with around 30 ideas for domain names of a particular idea, which I narrow down to about 3-5. But horribly, I can’t decide which one is the best (some people tell me it’s because I’m a “libra”), so I end up buying all of them.

And of course, I never end up executing on more than 10% of the ideas, and those that I execute, I usually don’t follow through with very well.

Which results in me sitting there with a pile of domains that I’ll never use, but will probably also not execute on. And as you could imagine, the names I end up getting are usually not the best ones.

How many do I have?

There are probably a lot of people out there that are much worse than me. But as the end of 2011 approaches, I decided to count them.

I have 49 domains.

Around 90% of them are .com domains. I have a few .co domains and some old .info domains, but mostly .com

If we say that it costs $10 a year on average to renew all these domains, it comes down to around $490 a year. That’s actually not too bad. Sure is a lot less than I’ve spent on car insurance, and so far I haven’t had an accident.

I have sold domains through the years, usually not that good ones and probably for way to little money to account for anything. But it happens.

The urge to collect: Domainbuyinitis

We humans collect stuff and I’m sure there are a lot of people out there who have a lot more. I wonder, to anybody who’s reading this, if there’s somebody who’s got a worse case of domainbuyinitis.

If you collect domains, please let me know in the comments.

That framework is pretty limited and TJ Holowaychuk pointed me towards Stylus, a much better sass complier for Node.js.

I tweeted something about Stylus a couple of days ago which resulted in a fellow countryman, named Jokull Solberg (www.solberg.is), showing me a responsive grid framework he made in Stylus.

So far it’s only a gist on github, but feel free to check it out:

https://gist.github.com/1501983

So far it supports four screen sizes, but it’s easy to extend.

The examples he covers are gmail’s edit-contact page and the button used to edit a project’s description on github. I’d like to talk a little bit about those and then give another perspective on hiding UI elements.

The Gmail example

Gmail’s contact editing is not stellar. But the fact that mr. Hoenig completely misunderstands how it works, really is an excellent indicator of how the whole contact editing page could be better.

Mr. Hoenig believes the delete contact button is only shown when you edit a contact’s name, but really the button he’s referring to is the “clear title” button. What’s wrong about that is a) it shows a trashcan icon b) the tooltip for the icon is “delete” which is really ambiguous c) there’s no other delete button visible.

In order to simplify it’s interface and reduce clutter, the gmail team chose to put the delete button in the “more” drop down menu:

I’ll admit that it’s very low affordance for that button, but then again, how often do you actually delete contacts? The action is also available from the same drop down when you’re in the contacts list view, in which case you would have a pretty easy time finding the action behind the drop down. So personally, it’s not that big of a problem, in my opinion.

But the problem with the “clear contact name” button is still there, and personally I don’t understand why you would even need a button to clear the name, since it’s hard for me to think of a use case where you would want to clear somebody’s name, especially where it’s not enough to just manually select the text and delete it.

The tooltip is totally misleading as well and the icon doesn’t help. Gmail team: You really should just get rid of that button.

The github example

Now, in the case of the github example, it feels to me like editing a project’s description is an uncommon task. I remember having done that possibly once or twice, and yet don’t remember having any problem finding the button.

Of course you could make the argument that it might be better to show the edit button closer to the description when you hover, but then again, some descriptions might be a bit longer than others, and the position of the button would be different between projects. So this solution is probably fine for the task at hand, in my opinion.

Hiding actions — good or bad?

Hiding user interface elements / actions is a totally valid user interface pattern in my opinion. If you have a lot of actions and tasks you need a user to be able to do, you really have 3 options:

1. Cluttering everything up with a lot of buttons
2. Putting the buttons on different pages/dialogs
3. Hiding them until they are in context

If you clutter everything up with visible buttons everywhere, it becomes much harder to find the buttons you are looking for. It also makes the design more busy and confusing and hurts readability of the content you are viewing.

Having to search for the buttons in different dialogs and contexts is not great either, so personally I feel that 3) is a great solution that both highlights the content you are viewing, doesn’t clutter things up and makes the appropriate actions available when you are searching for them.

There are some other examples of how web sites and apps hide actions until in context, which I would love to talk about in more detail, but I’ll probably leave that for a separate post.

When jumping between branches, continuing your work from where you stopped last time, etc., you very often open the same files as you were editing in a previous commit. This may not be a problem if you use something like Command-T for vim or rely on the file browsing in TextMate, but often it might just be quicker to open all the files from a particular ref in git or opening all files from your branch’s diff from master/dev or something.

I made this little snippet of a shell script that allows you to open all files from a git diff or show command in one fell swoop. Usage goes something like:

gitopen diff master

or

gitopen show 3663c033

or simply

gitopen

The command takes two arguments:

gitopen [diff <ref>] [show <ref>]

Where ref could be a hash or a branch name etc.

If you want to try it, you can download it here: https://gist.github.com/gists/1517095/download

Paul Rosnia also made a change which makes the script try to use the $EDITOR environment variable if it exists. You can override that if you like to use a different editor than is set by your environment.

If you find this utility useful, please let me know in the comments.

Update: Jarin Udom pointed out to me on Hacker News the following:

If you add a git alias, like so:

git config --global alias.open '!sh ~/gitopen.sh'

It will allow you to use the command like other git commands:

git open diff master

Apparently you should also be able to name the file git-open somewhere in your path, and that should have the same effect. However, it did not work for me and I have no idea why, but the git global config variable worked great.

Another approach for measuring page scroll performance

I wanted to be able to simply run a test anywhere on the page just for a single run, and I didn’t really care about the classes, since I was manually disabling styles and moving things around, unbinding event etc to find out where the biggest performance improvements could be had.

So I ended up writing this snippet of Javascript to aid me in my work. Drag this link to your bookmark bar / toolbar to try it out:

Arnor’s scroll performance test

You can find the bookmarklet-ready gist here: https://gist.github.com/1459352

Requirements

• The jQuery object ($) must be present on the page (I could make it non-jquery dependent, if anybody is interested enough)
• A browser that has a javascript console

How to use it

Visit any webpage that has the jquery object available and click your new bookmarklet. When it finishes running, it will display the stats in the javascript console of your browser, in ms. You can modify the code and add more runs if you want more consistent results.

The hacked up code

This is what the code looks like, if you’re interested:

How does it work

It basically scrolls a few hundred down and up 100 pixels, measuring the total time it takes to do that.

I had to make a hack to get the thing to get triggered more often – I believe that it’s because the browser is optimizing scroll events somehow – making sure the scroll event isn’t triggered way too often. So I wrapped the thing that triggers the page to scroll in a timeout thing. It’s probably not super super reliable, but at least I had pretty much consistent results.

Finally

If you have any questions, suggestions, bug reports or whatever, feel free to let me know by commenting or pinging me on Twitter.

I don’t expect to be maintaining this much or putting any more effort in it, unless there’s somebody else out there that will find this useful.

The guides are not very comprehensive at the moment, but they are written very clearly using a simple language. If you have some experience with Javascript, the guides should be perfect for you.

He also has a few other guides in the works and people are encouraged to contribute. So if you’re starting out doing server side javascript using node, this is probably the very best place to start.

A short summary of the guides

The beginners guide is pretty short. It teaches you how to install node, run your first hello world, a little about the packaging system and recommends a few web frameworks.

The style guide should be taken with a grain of salt. It’s good to have some standard but style guides have historically never been popular because most people like writing code however they see fit.

The convincing the boss guide is probably the most impressive, in my opinion. It’s very pragmatic and doesn’t try to sell you Node.js as the ultimate solution to every existing problem out there. He quite honestly points out that if you’re just trying to put together a simple web application there really isn’t much that Node can do that other languages/frameworks can’t do just as well. I think he even sells it a bit short, since in my opinion the upsides are more than he mentions.

That’s it.

I signed up the very minute it was announced and have had it as my default profile, though it hasn’t been viewable by anybody but me for some time, it’s dust has now settled a bit and I’ve been trying to digest it and form an opinion.

The Timeline is so interesting in so many ways. In one regard it’s got a very inconsistent UI compared to the rest of Facebook and it introduces a lot of UI concepts and ideas that have not been known to websites in general before but on the other hand it’s also a very pretty beast.

So I find it very interesting to think about and digest and both imagine what the developers were thinking and also think about if this is something that will be important in the future.

Evaluating the Facbeook Timeline UI

I just read this review / fan post about Facebook’s timeline. I usually like the author’s blog, but the article provides a pretty shallow view point on what the nice things are about the UI but doesn’t dive very deep into it or ask some important questions.

First off, I agree that the UI looks nice, and it’s definitely one of the more pretty parts of Facebook. It’s also very “Ballsy”. It’s a great example of the big risks Facebook is willing to take with its UI and compared to many other products out there, they’ve been very willing to do big changes, despite a large user base.

However, in my opinion, the UI also has its shortcomings. (Which I might very well be wrong about)

When you want to break something like the Timeline down and try to assess whether its good or bad, you have to first ask yourself the fundamental question: what makes this UI good or bad? And to find that out, you first have to ask yourself: what is the purpose of the Timeline? And what the user’s intent is when visiting somebody’s Timeline.

The intent of the user

The intents / incentives I can think of a user has when he visits someone’s Timeline (in no particular order), could be something like:

The user wants to…

• See what their friend has been up to  lately.
• Find a post again that they recently posted, but the user doesn’t have in their feed anymore.
• Interact with the user – either send them a message or write on their wall.
• View their photos. Either see photos of them or recent photos to see what they’ve been up to (or more likely: find a picture of yourself that they posted)
• Find a friend that they’ve added that you also want to add.
• A user visits his own timeline to find something that they posted, either to delete it, view comments (if out of notifications etc).
• The user doesn’t know the person, but wants to view their profile and maybe see what they’re like, what they’ve been up to, even though he doesn’t want to become friends with him/her.
• Find their phone number / email etc.

There are probably more intents that I haven’t listed or couldn’t remember, but those might cover 90% of the use cases.

Does the timeline solve those scenarios?

I think for the most part it does. It’s very easy to see what the user has been doing and posting lately. It’s easy to write on their wall, there’s a familiar textarea at the top-left of the timeline. Also, finding their friends is pretty easy: There’s a large box for that on the right side, and another similar photo-button on the timeline header.

The timeline uses these photo-style buttons to navigate to friends, photos, likes etc. (its probably a bit different depending on the user) – however I’m not so sure that they solve the navigation so easily.

Photo based navigation elements in the header

Finding a user’s photos is not as simple as you might think. Take my timeline header-buttons as an example:

The photos are much larger than the captions and when you skim over, they don’t exactly represent what you might be looking for. I think the main problem lies in the inconsistency in navigation from regular Facebook profiles, where photos, friends etc are usually placed as text links on the left side of the page:

Those links also have icons that we’ve come to get used to and associate with the given task. But in the timeline, those icons are not there.

There is no visual difference between photo, friends etc. So you actually have to read the labels. Especially since the thumbnail that’s shown is always different depending on what you last did etc. So the mental model breaks down a bit for plain navigation.

That’s not to say that a user gets completely lost, it’s just that it’s a bit less intuitive than you might imagine. It makes Facebook’s user interface a bit inconsistent and requires the user to learn two different methods of accessing the same information.

Finding a user’s phone number, email, etc.

We have a similar problem for finding user information, such as email or a mobile phone (if somebody lists those)

We are used to seeing the “info” link on the left side navigation on people’s profiles. But on the timeline, it shows up on the bottom left of the header, and it has also been renamed into “about” and when clicked, it now displays an alternative view of the about page you’ll usually see on Facebook.

That’s another example of an inconsistant UI where the user actually has to learn two methods of finding the same information.

Friends

Almost every single thing on the Timeline works and looks differently than it does normally on Facebook.

If you view somebody’s friends list, you don’t get the usual plain list, but you get a multi-columned view of them. It sure looks nice and you see large photos of them and visually it is more fun to browse. However, I’m not so sure a multi-column layout is good when viewing somebody’s friends, because when you’re skimming through them (they are in alphabetical order) and you want to find  a specific one, you need to move your eyes constantly in a z pattern to go through them.

It’s not immensely hard, especially since you have the search box, but for an ordered list like that, it makes less sense than a flat list.

Why the inconsistent UI?

I’m beginning to have the hunch that Facebook is changing its entire UI to something more akin to the Timeline UI elements.

The news feed itself probably won’t have a timeline view, but the way you browse friends, view a user’s photos etc. is probably all going to change soon.

I doubt that all the brilliant people working at Facebook aren’t aware of the inconsistent UI problems, so It’s probably a part of a unified move to a larger nicer UI.

Photos in the Timeline

The photos get arranged in the Timeline in a very visual and interesting way. Here’s a summary of an album I recently updated, as an example:

The really puzzling bit

Now what I find the most puzzling about the UI (and I might very well be the only one) is that the use case that the Timeline is mostly optimized for, is seeing somebody’s life summarized on a single page.

I think from an artistic, philosophical perspective it’s very interesting. It’s also enjoyable to scroll through people’s Timelines, and I’m sure if we had 20 year old profiles, it would be even more fun.

But its strange to optimize the most important representation of a person on Facebook for that use case. But that also means you are creating that use case. With that I mean, it is something people didn’t use Facebook for before, but could now be something you might actually go and seek out.

Personally I think the Timeline would serve its purpose much better as not a user’s main profile, but a user’s “life”. It’s something you don’t go and do very often so I feel that it’s strange to just push the user into that scenario.

I’ve rarely found myself scrolling very far down.

The societal hurdle of scrolling down in somebody’s Timeline.

There’s another thing that keeps me thinking.

When I make friends on Facebook with users that have the Timeline enabled, the first thing I find myself doing is scrolling a bit down and checking their Timeline out.

But it also awakes a strange feeling within me, which is that I almost feel like I’m nosing in people’s personal stuff. Almost like looking in somebody’s bag or looking through their personal photo album without consent.

When it’s somebody I know very well, I don’t mind at all. And personally I don’t mind the thought that my friends might be scrolling through my Timeline a few years back.

But I feel guilty about doing that in Timelines of people that I don’t know. That is a really surprising facade of a website which I’m not very used to.

Conclusion (if there is one)

Like I mentioned before, I am very impressed with the Timeline. It does a lot of interesting things and it will be interesting to watch what Facebook does with it in the coming months / years.

There are some UI issues in terms of consistency which I suspect they’ll address as well very soon and there are some puzzling things, especially the fact that they’ve optimized the Timeline for a totally different use case than the one that you might expect a new profile to be optimized for.

This has been a bit of a long post, and I’m probably diving way too deep into this, but I hope it has been somewhat interesting.