Let’s just say Twitter is not on my radar (anymore)

I am still on Twitter, I am just choosing to ignore it for as long as I can these days. There are many reasons why (and that’s probably left for another blog post), but the whole death of the developer ecosystem that brought them where they are today is part of it. But I digress. Let’s talk about something more interesting.

Making an App.net web client

So one weekend a little over a month ago, I created an App.net client. Since I already made Noodletalk (a realtime chat with support for embedded media), I decided to port the core media functionality to this new client.

Well that was a pretty fun weekend hack! The result was something like this:

Challenge #1: Make it work in all devices

NoodleApp was built from the ground up with responsive design first. Although limited to two possible sizes (325 pixels wide and 610 pixels), it ensures a reasonable experience in desktop, tablet and mobile views in modern web browsers.

This means when we resize on the fly, all media must also resize without a screen refresh and still work. But it also means not making the content too wide and ruining readability (ideal maximum reading length of text on a page should be around 12 words or 50-60 characters including whitespace).

Challenge #2: Add as much functionality available in the app.net API (within reason)

It’s really tempting to add everything we can to make a full service client - because that’s what people want, right? No, people don’t really want that. Honestly. People want to have a great experience in the application they are using but this doesn’t necessarily equate to adding more features.

Adding too many features will limit your ability as a developer/designer/producer to focus on what makes your app unique and interesting. It bogs your code down and makes it difficult to maintain when you want to move things around - even writing tests that have 100% coverage won’t save you from the inevitable problems in usability.

Even though NoodleApp isn’t the most perfect web client in the universe, we mindfully listen to what people want in terms of feature requests, look at the current application state and constantly trim and polish accordingly.

If something will make 80% of people happy then it has a higher priority for being implemented - but if it creates a high risk environment of “we really don’t know how people will react to this once it goes live”, it is held off until we cater to more pressing issues (like bug fixes and making the current interface fast, usable and pleasant).

Challenge #3: Make it reasonably fast

Web applications that require multiple server connections will not run as fast as your iPhone’s Todo application, where nothing ever hits an Internet connection and everything is saved locally on the device.

There are a few key things that happen when you load a website or web application:

1. Your computer checks to see if the other computer (server) is alive
2. If that server is alive, it needs to make some calls to the API server (in this case, app.net)
3. The API server returns the request, and then first server has to process that request
4. The processed request is rendered to the pages you see, using a combination of JavaScript, HTML, CSS
5. Rinse and repeat

So we have to do our best to make sure the experience isn’t too slow, we cache appropriate items without having to get into a caching nightmare (did you know caching is hard?) and try not to do too many clever things in JavaScript that can and will slow down your browser. Especially the browser on your Android or iPhone device, which doesn’t have as much power and support as your desktop computer.

Challenge #4: Make it pretty (minimal)

Remember all those features that were so tempting to put in but we have to balance them in the fine art of product design? This is where things get complicated and difficult.

There are many features we would like to put in right now (and we even have test branches for trying them out), but the app is not ready to have them implemented. If we were to just throw them in and deploy, there would be many complaints about more bugs to deal with, slowness, strange behaviour - I mean, we already get those bug reports! Imagine if we wanted to be extra masochists and apply more gasoline to the fire!

We would have to add more icons (which generally are a bad thing to use in an interface since nobody knows what anything really is) and the space would get cluttered really fast. So the only solution around that is to add subsections that appear in submenus and let’s be honest - nobody likes submenus. They just accept it as a necessary evil but I don’t like accepting sub par solutions. NO SUBMENUS.

Current result

Well, we tried our best (so far!) and this is the latest iteration:

Lessons Learned about building an app like this?

1. You can’t please everyone all the time. You can only please some people some of the time.
2. Do what makes sense for you and your team. You are the ones building it so it should reflect your personalities or else it will feel inauthentic to your audience.
3. Try, try and try again. And iterate often (but too much change in a short period of time is bad)

Thanks to the wonderful contributors!

It wasn’t just me who made NoodleApp! I did get a lot of help (big and small) from various contributors - because this is an open source project under a BSD license

Thanks to everyone listed as contributors - we couldn’t have done it without each other!

Last but not least …

Thanks for our supporters that enjoy NoodleApp - your suggestions and feedback helped make it what it is today.

Oh yeah …

If you are on app.net you can try out NoodleApp too!