From Two 2 Twelve - general

How A Sensible Navigation Flow Is Crucial to Application Design

2008-06-18T18:11:00Z

During my recent revocation of the 72photos photo hosting service, I came across multiple hurdles in the lines of navigation. I’ll spare some of the more gritty details, but I will add, if and when your site begins to employ multiple areas such as, a separate website and client backend for instance, it’s crucial to have a navigation flow thats easy to follow, somewhat static (i’ll elaborate on that shortly) and most definitely sensible.

Here was the progression of navigation used on 72photos which consists of 2 separate sections, the main website and a user’s control panel area:

Version 1:

Main website: Displaying a set of links pertaining to navigation for the main website’s pages. The active link (the page you’re currently on) is subtly underlined.

Users backend: Displaying a completely different navigation from the main website with links pertaining to sections in the users backend.

Why this doesn’t work: Once a user was in their backend control panel, the only way to navigate back to the main website was to click the 72photos logo (not effective). Reversely, the only way to get to the users backend from the main website was one link entitled “dashboard” which replaced the “home” button on the navigation once a user was logged in. Since the main website and user backend designs changed dramatically from a dark design to light, a feeling of seperation would overcome to user when switching between the 2 interfaces with no elements constant to give the feeling of connectedness and flow throughout the system.

Solution (Current Version):

Main website: Redesigning the set of links to use the colors from the footer and highlighting the active link distinctly sets a tone for the main navigation which is now shown on every page/section of the application.

Users backend: A redesigned and re-aligned set of links as before, however, this time around the main websites navigation is still up top.

Why this works over the former: The constant, site-wide navigation up top gives users the ability to explore the entire website at any time and to always know where they are—where they came from. The new backend navigation cleans up the interface and keeps the header a reasonable size even though it now employs 2 separate navigation’s.

Final Thoughts:

I can’t say for certain my approach will work for you but as long as the most sensible items are in your main navigation and are always present you’re application’s usability will go up a few points.

Also, Throwing your entire applications site-map in an over sized footer bar is never an appropriate solution (speaking from experience).

It's 2am, Do You Know Where Your Log Files Are?

2008-05-15T06:21:00Z

So, I was having just another ordinary night, you know, where you’re converting some video files for your iPhone instead of doing something truly productive, when I received my first “low disk space” warning on my Macbook Pro. This came quite to my surprise as I had thoroughly inspected my disk space usage that very morning (yes, I’m a power-geek) and noted 60GB was available. Now, considering the video in question I was encoding was roughly 30MB, I concluded this sudden inflation of used space wasn’t a possible side-effect of my extra curricular encoding activities.

To investigate, I ran a quick WhatSize in hopes to find the culprit and found it was coming from my very own OS X Log files. Now, being in a full-blown panic state, not knowing if my logs would keep inflating—rendering my computer useless (It could happen?), it took a great deal of restraint to not just delete every log file I could find, but instead I googled it to get some insight on what exactly one should do in this situation. Sure enough, deleting every log file in sight was the preferred solution, so I did just that.

After this entire ordeal, I’ve concluded this is in fact, quite a unique problem, but considering this is my 6th time cycling my logs (since that first night) i’ll take my chances and bet you’ve had (or will have) the same problem at some point.

Now if you are however, currently experiencing this same issue, I have indeed conjured up a somewhat more elegant solution then the constant metal juggling of your log file sizes with a spare finger on the “delete” key. It’s a little, freeware application called OnyX and can be scheduled to run and clear your log files automatically. There are other applications that do this same function aswell (Cocktail to name one), so if you find something your more partial too, firstly, clue me in ;-P and secondly, make sure it’s set to cycle all log files.

Transmuting this blog...

2008-05-04T19:23:00Z

Up to now this blog has focused mainly on my personal web endeavors and various technical ramblings of that sort. However, lately i’ve been compelled by the possibilities of blogging and it’s ability to influence others based on ones personal experiences (yeah, I’m a bit late catching the blogging boat). As a result of this revelation, I have been inspired to transmute this blog into something that encompasses more aspects of my persona (which could be good or bad for the general public, we’ll see).

You can now explore my web portfilio, photographical hobbies, attempts at becoming a rockstar, and fascination with moving pictures.

Hopefully you’ll find something of mutual interest here, or perhaps be introduced to something new. Either way given the broadness of content to be contained, there’s certain to be a high level of ambiguity, which I’m hoping could make things a bit suspenseful, no?

Collective Consciousness Indeed

2008-03-19T18:41:00Z

It appears the folks over at Ajaxian.com are having parallels thoughts to my own and have recently reported on a new project called “ProtoSafe” enabling Prototype to be more 3rd party friendly.

It’s not the most elegant solution, however it surely beats methods I’ve used in the past for using multiple javascript libraries (refer to my last article for details).

Head over to Protolific and check it out for yourself.

Why Not To Exclusively Use One Javascript Framework

2008-03-14T05:10:00Z

Since I began using Ruby on Rails I’ve never really thought of using any other javascript framework except the standard Prototype/Scriptaculous pair regarded as the rails standard. I mean, who could blame me, with all those JavaScriptHelpers and fancy RJS templates to entice you. But, don’t get suckered it by these mere facades, as a result, your application may suffer. I’ll explain…

While programming some additions to my photo hosting application, 72photos, I found the need to add functionality that was particularity difficult to do in Prototype. I’ll spare you the actual details, but as a result of this conundrum, I turned to another Javascript framework, which was, what I believed was the enemy, until now…Mootools. Sure, I heard the hype surrounding mootools of late, however, my loyalty to Prototype/Scriptaculous clouded my judgment to explore it more throughly. When I decided to give a decent look through mootools documentation, I noticed it’s very elegant syntax and it surely made more sense in areas such as event handling.

Where am I going with this exactly? Well, If you’re currently loyal to one Javascript framework and it works for you, I’m not suggesting to break out of your current comfort zone. However, I wouldn’t suggest putting aside features or avoiding them because your framework doesn’t support what your trying to do or would take more time then desired to implement. There are other options and I advise you have a look around regardless. Theres no problem using 2 or even 3 separate frameworks in 1 application, surely you’ll have to watch out for incompatibilities, but theres always a workaround.

Personally, I love Ajax/Javascript, it gives life to what would otherwise be a stationary application. A word of advice…If you’re one who relies on RJS and JavascriptHelpers in rails, I highly recommend learning exactly what those helpers do and how to reproduce that particular code in pure javascript unobtrusively. You will benefit with such knowledge in future endeavors.

Oh the possiblities of Slingshot...

2007-11-04T16:57:00Z

I’ve been working lately with a new framework called Slingshot by Joyent. It may have gotten some initial hype when it was released a few months back, but since has died down quite a bit.

Basically Slingshot allows Ruby on Rails applications to run offline as a normal desktop application, plain and simple. Joyent have built wrappers for Windows and Mac OS’s in which wrap a Rails application and port it into an offline runnable form. Sounds amazing, I know, however, there are several drawbacks, none crippling, but drawbacks none the less. It’s a bit rough to forsee all these pitfalls and bugs just by reading their wiki, So, i’ve felt compelled to document my experiences with the framework and how I’ve so far, managed to get past some hurdles. Also note, my testings up to this point have solely been on Mac OSX Tiger.

Just by reading their introductory write-up you can see the potential and with a quick browse of the wiki you can get a full idea how everything works (compared to the more complicated and incomplete Adobe AIR).

Here are a few issues i’ve faced in building my first Slingshot application:

Size: The size of Slingshot is insane. The base framework is roughly 130mb, which basically is unable for a production app.Why is it so big you may ask? Well, I did some digging into the source and Slingshot actually contains a full version of the Ruby language. So, my quick solution was deleting all the .svn files, deleting all the RDocs, tests and examples for each gem that was installed. After that, We’re down to about 27m, much better, still a bit high, but, we’ll deal with that more in depth later.
Open Code: Another drawback of Slingshot is the fact your Rails application code is completely open to viewing being that it resides in a sub-directory that is accessible by simply right-clicking the app and viewing the contents. Now, I haven’t come across any viable mac encryption methods (not sure if Windows has a solution for this either) and giving users full exposure to your source code is not an option (unless of course you’re taking the open-source route). Im my case, I’ve built an API for my main application (a web application), wrote a ruby library for the API, and am now using that API for my Slingshot app, which I have no problem with users being able to view.

So far those we’re my main concerns, now for some positives:

Performace: After opening Slingshot with a newly created rails app, the performance is superb. CPU is at 0.00 and memory is just over 13mb. We’ll see how this continues after adding some more ajax libraries and graphics.

Interface: The great thing about Slingshot is it has the look and feel of any mac application and with Interface Builder you can tweak and edit the menu bar, etc… for even more customization. Changing the application name and icons are very simple, so branding is very simple.

I’ll keep you updated as my application progresses, but so far it looks extremely promising if your in an abiding position.

Let me know if you’ve done any experimenting with Slingshot yourself, i’d love to compare notes!

To Beta or not to Beta

2007-05-11T16:56:00Z

It’s been often talked about whether new web 2.0 services or new internet services in general should enter that proverbial public beta stage rather than holding off and releasing a polished, final product. I’ve been increasing noticing the beta phase being something more accepted and implemented in the web 2.0 community as new services emerge. With XMG Image v2’s release on the horizon, this particular topic has come up quite often in my thoughts when getting ready for deployment. On one side with the beta option, is the idea of getting feedback from users, as there are no better improvements to be made on your application then user-suggested ones. But on another note, this beta stage could be rather irritating to a user who’s constantly dealing with bugs and unexpected events while using your system and at worse, could result in lost clientele. So, before we can make a calculated decision, we need to look at all sides of the story…

Now, before even considering a public beta phase, you need to first have a clear definition of what this so called “beta” phase will actually consist of and the obvious aspects must be taken into account such as; the market/industry your service is in, what your service is trying to accomplish, and the overall magnitude of your application. With that said, for XMG Image, the service is; targeting a fairly unsaturated market, trying to accomplish things in a smoother more user-enjoyable way, and is fairly robust as an application. So, with much emphasis put on usability and the lack of much notable competition in our market, a public beta seems like the most reasonable choice to carry on with.

Now that we’ve established our service is going to head for a public beta, there are some things you should consider before diving into beta and throwing you’re unfinished, possibly buggy system out there for the public to beat the hell out of and send loads of bug reports to you for. For starters, be sure to have a clear definition of what your beta release will actual consist of and what you expect to get out of it. For XMG, entering a beta stage doesn’t mean releasing an incomplete, buggy product, that’s not even going to accomplish its primary functions without encountering bugs. It still means getting 100% of the application finished and all its functions tested from a developer’s standpoint. Leaving the “beta” part more for users feedback and suggestions that, when implemented, will further evolve your application, not to get things working as you initially planned (that’s just being lazy :-P).

Entering a beta stage can be extremely beneficial to new services, but could also be a miscalculated move. Be sure to figure out exactly what you expect to get from your beta stage and take in as much user feedback as you can get from it. It will definitely come in handy when getting ready to revamp your service.

Transforming XMG Image to v2 on Rails

2007-03-20T16:55:00Z

From the inception of XMG Image, it’s goal has been to provide a simple, effective and easy-to-use way to upload and manage your images online. Trying to offer a more intuitive system than others like ImageShack and something a little less social and more robust like Flickr.

Unfortunately, XMG Image v1 was designed and coded in a time before Ruby on Rails and inevitably declared an end-of-life system almost as soon as it was released. But, with my newly acquired knowledge of RoR, I decided there was no better time than the present to shift development towards v2. In doing so, Rails has not failed to deliver as an immensely powerful development framework which completely streamlines the development, testing, and deployment aspects of building a robust web application.

But even as v2 reaches it’s proverbial beta testing phase, the general public, even XMG Users, have no tangible evidence that development for v2 is even taking place (except for this flashy splash page). So here, I present a quick screen shot of the new customer dashboard, and I must admit, it’s dead sexy…

The initial release date is still hard to predict since private beta testing is currently going on. Also worth mentioning, v2 makes heavy use of Ajax/Javascript, so testing has been a challenge.

As for the service itself, there will be 2 plans offered, a completely free plan, and a yearly subscription plan (roughly around $14/year), which will give you access to tons more features and our built-in support ticketing system.

More info on the release will be available here and on the XMG forums as it gets closer.

Feel free to leave a comment/opinion on the new interface!

My Thoughts on Developing Web Applications

2007-02-05T16:30:00Z

I’ve always been a developer who looks to try new things with applications I develop, there is rarely a time where someone will come up with something that hasn’t in some way, been done before, and with frameworks like Ruby on Rails and Ajax on the rise, trying new things has gotten undoubtedly easy, almost too easy….I’ll elaborate: During the development of my most recent web application (XMG Image v2) I visualized a new way to accomplish image hosting built with Ruby on Rails. So, coming up with a concept was the easy part, which is usually not the case when building applications with languages such as PHP, where technological hurdles can often constrain creativity. In my case I like the approach of build-as-you-go but still have a clear structure of the application in your head. XMG Image being the first major Web 2.0 application I’ve undertaken, that ideology has been working pretty well for me so far.

I do however; enjoy the current state of web applications and where they’re going. Applications like Basecamp and Shopify put a twist on things that have been relatively done before, but rely on usability and functionality as they’re selling point. This is what I hope to accomplish with XMG Image, as i do realise image hosting has been done before (but none to my satisfaction).

The goal for web 2.0 applications I develop isn’t to re-invent the wheel or replicate things that have already been done, more so, to explore other avenues in building intelligent web applications.

The Obligatory First Post

2007-01-15T16:02:00Z

Well, here goes.

The first post is always the most difficult I say. No matter how many blogs you maintain or how often you write, it seems as though the obligatory first post is the most difficult to come up with.

Is the first post supposed to start a trend? Introduce the blog? Perhaps neither of the above!?

Well, I’ll start off with my most recent life-changing experience:

It all started a few months ago when I stumbled across hype of a new programming lanaguage framework that was quickly growing in popularity among ‘Web 2.0’ followers…The framework in question is called Ruby on Rails. Curious, I checked out a few articles on this so called ‘Ruby on Rails’...reading the first article I found, at that moment, I realized my entire life was about to change…

I didn’t even bother to finish reading the article when I raced down to my local bookstore to pick up a copy of anything that had the words ‘Ruby’ and ‘Rails’ in the title (though I wish I had done a bit more reasearch on that, as I ended up with a load of completely irrelevent novels)...However, I did end up finding the holy grail of Ruby books, 2 mainly, entitled “Agile Development with Rails” and “Programming Ruby”.

Shortly after reading a few chapters I bounced right into it. Then things started to get a bit hazy…I remember fading in and out of conciseness while seeing spots and swirls of red while my head spun to a stop. Moments later I reoriented myself enough to just barely stop myself from falling out of my chair. Too much drama? Perhaps, but believe me when I say this isn’t far from the truth.

The fact of the matter is I wasn’t having some type of epileptic seizure…but was actually experiencing a Web Framework that actually makes sense!

That’s right. For the first time in my life I went through an entire web framework and didn’t ask myself “Whaa?” or “Why the hell did they do that?” Instead I found myself saying hmm…”Why didn’t I think of that?”.

The Key points I find in RoR that are absolutely brilliant are:

Ruby is a ‘Readable’ Code, meaning, even with minimal programming experience you can understand to an extent whats going on.
The pricipals and structure of the language make sense, If you’ve coded PHP or Perl with any seriousness in the past you’ll understand how primitive RoR makes those languages look.
The language employs one of the most important programming tools in my opinion: Common Sense.

The bottom line is, it just works. Nothing else that I have ever encountered has made so much sense. That my friend is a moment of clarity that just cannot be ignored.

If you currently employ any language that doesnt have the word ‘Ruby’ and….ok, nevermind that, just go find any Ruby on Rails article you can get you’re hands on and prepare to experience programming enlightment like never before.