Die IE6!
IE6 (also affectionately called Internet Exploder by some) has been a huge burden on the web as a whole for several years now. While the average web consumer might not notice it, the ubiquity of IE6 has forced web developers and designers to jump through many arbitrary hoops in the past to support the non-compliant browser.
This has meant that precious development and design resources over the last several years have been slaving away at making IE6 look good, instead of focusing on making web sites/apps/designs work better. This also has meant that one major strength of the web (portability) was hampered by the need to address a specific platform.
The good news is, several companies are beginning to drop support for IE6, in favor of more recent browsers, most recently Google. This is not surprising for Google as they have been pushing alternative browsers like Firefox and, more recently Chrome for a while now.
For web developers, this comes as great news - there is now a major web player moving the masses away from IE6, which hopefully accelerates the adoption of newer generation browsers.
For Ronin, we’ve never really supported IE6 to begin with and we’ve seen no reason to really bother with bending over backwards to begin supporting IE6 now that it’s hopefully on its way to the grave. Analysis of our traffic shows that only 16% of our traffic comes from Internet Explorer, and of that 16%, roughly 20% use IE6.
The chart on the left shows that the majority of our users prefer Firefox and the rest use Safari. Surprisingly, this doesn’t mean most of our users are on Macs - instead, Firefox/Windows is still the most popular combination.
This certainly has to do with our audience. We primarily attract high-tech professionals (whether its freelancers, design firms, small businesses) and with that tech-savvy crowd comes the preference for newer, more standards-compliant browsers. In fact, it would be a lie if I told you we didn’t have this fact in mind when we first started Ronin.
Here’s to a new year and leaving behind old worries!
Support for more currencies
We’ve recently added support for four more currencies: JPY (Japanese Yen), INR (Indian Rupees), CHF (Swiss Francs) and NZD (New Zealand Dollars). You can now send those invoices in 10 different currencies.
In adding support for more currencies, we wanted to make sure we included currencies that are “the most popular” (whatever that means). Surprisingly, there was no definitive resource that lists out the most popular currencies by any decent metric, unlike say, languages, where the list is easy to find. We did run across this discussion which seems to indicate that this is a question that people want answered.
Eventually, we ran into the list of the top 8 most traded currencies in the foreign exchange. Not surprisingly, that list looks very similar to the list of supported currencies in Ronin. Oddly enough, the Russian Ruble and the Brazilian Real were not present, despite being high up on the top economies list.
Lazy Loading JavaScript
Most of us know it’s best practice to load your JavaScript at the bottom of the page for performance reasons. The Yahoo! developer network explains the reasoning as follows:
It’s better to move scripts from the top to as low in the page as possible. One reason is to enable progressive rendering, but another is to achieve greater download parallelization.
What typically is not discussed, however, are the potential issues that arise when you follow this development rule-of-thumb. I hope to talk a little bit about this issue and a nice workaround that I like to employ to side step the landmines.
Uh-oh, JavaScript errors
Consider the following code block:
<body> <div> <a onclick="foo(); return false;" href="...">click me</a> </div> <script src="...defines foo..." type="text/javascript"></script> </body>
This complies with best practices for performance, but the astute developer will note that there is a small interval of time between the rendering of the a tag and the script tag. This means for that interval of time, a user could click the link and trigger an undefined function. That’s no good.
This problem is actually more pronounced than you might think. If you’ve ever watched users over the shoulder, you’ll know that some of them can be very click-happy (and they’ve every right to be). They don’t expect to wait for the full page to load before taking an action. Why should they? Isn’t that the whole point of progress rendering?
Also, this is a bug that tends to slip through the developer radars. We tend to wait for the entire page to load when we’re going through our code, save, refresh RAD cycles, probably because something inside us knows to wait for the page to “stabilize” before attempting to test that one feature we just coded up.
Wrong answer (sorta):
Purists will note that the best solution to this is to remove the onclick attribute from the HTML and instead load it during the onload (or DOMLoad) event within JavaScript. This frees up the HTML so it is just content and moves all the interactive stuff into JavaScript (the application layer) where it really belongs.
I’m actually not opposed to this reasoning, but for the purposes of shaving off every millisecond of lag, this solution will not work. There is still an interval of time between the rendering of the link and when the JavaScript attaches the onclick handler. Clicks during this time won’t register JavaScript errors, but they’ll either trigger the actual link or do nothing, depending on what you have set in the href attribute.
If you’re happy with that, great. If not, read on.
An example workaround:
Supposing that foo is a hefty function, we really do want to load it last on the page. This is especially common when foo is part of a larger framework or rides on top of said larger framework. This is because beastly libraries like prototype ought to be loaded last on the page if possible.
We can try the following:
<head> <script src="workaround.js" type="text/javascript"></script> </head> <body> <div> <a onclick="bar(); return false;" href="...">click me</a> </div> <script src="...defines foo..." type="text/javascript"></script> </body>
and in workaround.js:
function bar() { var closure = function() { if (typeof window.foo == 'function') { foo(); } else { setTimeout(closure, 100); } } closure(); }
Oooh, self referencing closures. That’s got to solve the problem just from sheer awesomeness, right? Let’s break down what’s going on.
Instead of calling foo directly, we’re calling bar, a function that we hope is lighter-weight than foo, since we’re allowing bar to be the exceptional bit of JavaScript that is loaded in the header. bar simply checks for the existence of foo every 100 milliseconds until it is loaded, at which point foo is called. Alternatively, onload could be employed, which is typically not as fast as polling every 100 milliseconds. Yet another alternative would be to employ DOMLoad, but you’d have to include extra JavaScript to get a cross browser friendly version.
But wait, there’s more
bar and foo are cute for example purposes, but we really want to generalize the concept.
Try this instead:
function safecall(func) { var closure = function() { if (typeof func == 'function') { func(); } else { setTimeout(closure, 100); } } closure(); }
The calling HTML should be:
<a onclick="safecall(foo); return false;" href="...">click me</a>
If you want to pass parameters, you’ll have to employ closures, not that you don’t want to.
<a onclick="safecall(function() { foo(arg1, arg2)}; return false;" href="...">click me</a>
Geez. JavaScript is powerful. The closures I mean - not the part where I just spent several paragraphs detailing what is essentially a hack.
Conclusion
We’ve defined a function safecall that can be defined as the sole script in the head tag which can be used to protect unloaded JavaScript that is sitting at the bottom of the page. Hopefully this will solve someone’s development headaches trying to fix all those new JavaScript headaches when someone in the office decided it would be cute to move scripts to the bottom of the page.
New Product Feature: Estimates
We’re always looking to improve our offering here at Ronin, and one feature we’ve received several requests for was the ability to send estimates. Unfortunately, everyone’s daily workflow is different - drafting and sending estimates is no exception. We’ve tried to incorporate as much feedback as possible, and while we’d love to including every feature detail from numerous email threads about this feature with our customers, sometimes we have to call the shots that make sense.
So log in to your Ronin account and you’ll notice a new estimates tab. Hit the “New Estimate” button and you’re on your way. After drafting the estimate, hit “Send Estimate” and your client will receive the estimate in his or her email. The client can then respond by leaving comments, accepting or declining your estimate.
Estimates can easily be accessed from the main interface
Send estimates to clients via email
Clients can accept or decline estimates right in the web interface.
It’s all very simple (we hope) and there isn’t too much different about drafting an estimate and an invoice. We hope we’ve nailed it, but we’d love to hear any feedback.
Entrepreneurs wear many hats
The recent trend of new businesses moving towards software or, more specifically, the web, seems to lead more and more would-be entrepreneurs into falling victim to the myth that building a solid product is necessary and sufficient for success. Some would go so far as to believe that cool technology alone does the trick. Many from-thesis-to-market product failures demonstrate the naiveté of current entrepreneurial thinking. All to often, we are led to believe that awesome products sell themselves.
Conversely, the other end of the spectrum finds no shortage of MBA’s looking for “code-monkeys” to implement their visions. The mode of thought here centers around the million-dollar idea, from which execution supposedly willingly falls into place. Here we are led to the believe that awesome ideas lead to awesome products that sell themselves.
The code-monkey and MBA both fall prey to the instant-noodle brand of business development: “1) idea 2) build 3) ??? 4) profit.” Battles are fought over whose position is more important, the tech guy or the biz guy. Techies are all too-often devoted to proving themselves to be in no need of the MBA types, while the business minded are just a lost looking for hired guns to prototype a lost cause. Lost in all this back and forth is the unerring truth that none of it matters.
For centuries on end, entrepreneurship as been defined outside the lines of technology. Look up “define: entrepreneur” on Google and the common theme that arises in each definition is the word “risk”. Not “new hot technology”. Not “brand new business idea”. While it can never hurt to have new hot technology that powers a brand new business idea, it is neither necessary nor sufficient to get a business off the ground.
The age old fact of entrepreneurship is that there is so much more to “risk” than the product and its development costs. Establishing or building your market, generating or growing revenue, finding distribution channels, building a sales pipeline, hiring the best talent, and all the other caveats that come with building a business are just as important as product development. A true entrepreneur must wear all these hats, not just the product one. A recent blog entry by Tony Wright talks about the product guy vs. business guy with the conclusion that a good product entrepreneur should grow into a business role. While I agree, I would have to say a great entrepreneur can never take off either hat.
Be a business that sells a product, not a product that happens to be a business. Be an entrepreneur that builds business, not a product person that happens to be an entrepreneur.
Freelancing for Money
There was an interesting article I came across titled “12 Killer Ways to Make Extra Income On the Web“. The article is interesting because there was only really 1 killer way that is even worth mentioning, and that is “Freelancing”. All of the other recommendations are either a waste of time or require much more effort than simply getting paid to produce good work. The age old “do-work-for-money” will never go out of style. If you’re good at what you do, of course you should be getting paid well to do it.
However, like all marketable things, your personal time is something that you should price with careful consideration. Unfortunately, there is one business model that is cropping up across the web that is counter to this. These sites (typically targeted towards logo or web design) allow you to submit entries for a chance to win a small cash amount ranging from several hundred bucks to maybe a thousand dollars for a winning entry.
Without being religious about NOSPEC, my advice is to steer clear of these “contests” unless you are simply trying to get your feet wet with design (or whatever industry you’re jumping into). There are various reasons that people throw around, but in my opinion, if you don’t value your time and effort, why should the client? If you really undervalue your work that much, maybe it’s because you consider yourself an amateur and not a professional. Also, on the flip side, clients that flock to these sites typically have no appreciation for the good work that professional designers can produce. As a friend of mine once aptly described it, it is like these folks couldn’t tell the difference between interior design and interior decoration.
Show respect to your own profession, lest you sarcastically post a blog entry entitled “Why I hate freelancers.” Whether it is web design or software development the good clients out there are looking for real professionals, not amateurs.
The Seven Archetypal Software Projects
Throughout any given software developer’s career, I think he or she is bound to run into a few archetypal projects. Some are good projects to have experienced, others not so much. Either way, I find these are the projects that offer up the biggest smack-in-the-face lessons.
I also find that the order I’ve laid out below tends to mirror the progression of a software developers career chronologically as well.
The school project
I love this one, because this is where a large number of hackers become “software engineers”. Or so says the industry and HR people. The only reason I value this type of project is because it’s such a stark contrast to how development happens in the real world. Somehow, the particular mix of apathetic group members + hero group member + late nights in the computer lab makes for good memories to reminisce after you’ve been in the software industry for a while.
The “I can do that in a weekend” project
Don’t lie - the first time you saw twitter you said, “I can write that and more in a weekend.” Maybe not twitter, but we’ve all run into successful apps and scratched our heads pondering what the big deal happens to be. So go ahead, write it. Build that app. Then eat dirt. I find this is the fastest way to learn that 1. no, it’s not that easy, and 2. even if you built and launched a me-too app, no one cares.
The “I’ll build it from scratch” project
This is another one too many of us have had the guilty pleasure of partaking in. Instead of taking well-known and well-document open source solutions already out there, you decide you can do it better yourself. More often than not, you walk away with a new appreciation of that whole shoulder-of-giants saying. Then you start shopping.
The “other platform” project
Everyone gets curious about the greener grass on the other side. So appease the need. If you’re a *nix/apache type, give .NET a shot. If you’re the .NET type, give open-source platforms a shot. Loving Java? Try C#. RoR expert? Give Django a shot. Learning both sides is not so much for gaining actual experience as it is for gaining perspective. My personal experience has shown that you just might stay on that new platform. (Of course, most of my experience has been of the Microsoft camp going open source.) At worst, you’ll know you validated the choices you made going into your current setup.
The “coding as a job” project
If you haven’t already, get a job (at least once). It’s a quick shot of reality and harsh perspective. It helps you realize what engineering in the wild is like. Product managers, program managers, project managers, mid-level managers vs. you. It helps you realize whether working in a team is your strength or your weakness. It helps you learn to curb that ego of yours. It makes you appreciate just how difficult running a business is, aside from the technical side of things. Observe the sales people, watch the BD team. Learn their tactics, their way of doing things. It will make you a more well-rounded individual. If nothing else, you’ll learn what kind of software and services the suit-and-tie crowd really need.
The startup project
The beauty of software is that everyone’s got an invitation to start something up. This is more than just a “all the cool kids are doing it” thing - I feel that everyone should try to build a project (and eventually product) that brings real value to people. In fact, try charging for it. Nothing validates your ideas, concepts, beliefs, and ambitions more than getting others to give attention to what you’ve got to say or sell. If you fail, no big deal - you’ve learned something valuable and chances are you lost nothing but a few weekends and hosting money. If you succeed, well then it’s all the more rewarding.
The open source project
This is where the “end-game” of software development happens. You go through life looking for projects to be passionate about. You’ve gone through school and pulled through the grind. You’ve tried the whole day job thing and you’re either feeding your family or you’re looking for a new cause. You’ve done your own start up, for better or for worse. In the end, you begin to realize nothing is better than sharing your great hack, tool, technology, algorithm, framework, project, or application with the world. I find that the sense of accomplishment that comes with open source projects spans the spectrum from being the sole maintainer of tiny, obscure plugin to being a drop-in-the-bucket contributer to a massive framework.
What comes after the Web 2.0 lottery?
I feel like today is the day after the lottery for all of web 2.0. You know, the day where you look down on your ticket comparing your numbers to last night’s numbers. Then you sigh. Game over. You just lost your dollar.
Oh wait, but I forgot, the lottery is for under-educated poor folk who are desperate to get rich. What’s the difference between that and the game the Silicon Valley has been playing for the last 2 years? What’s the difference the lottery and the game played in the early 2000’s? From all of this web 2.0 stuff, we’ve basically learned that the exceptions (Google, Youtube, Facebook) got rich, while the rest got/are getting shafted.
However, when one door closes, another one opens.
First, this is a great opportunity for businesses with legitimate, sustainable models to separate themselves from the rest of the pack. More signal, less noise for all of us. Similarly, this is an opportunity for those with unique talents to find themselves in smaller, leaner, more efficient teams. At the end of the day this will reward responsible companies that curb spending and reduce burn-rates.
Second, the opportunities for areas outside of consumer web space finally have a chance to shine. No more showing up for VC pitches only to be asked, “does it come with a Facebook app?”. Companies that focus on selling actual products with actual price tags will be rewarded.
Third, for developers, a whole new world of viable alternatives opens up. The Rails community seems to be happy about the opportunities present in the downturn. However, there is no better time to start your own indie developer shop. For example, maybe it’s time to start desktop development again - the market for Mac software products grows with each day, and incumbent developers will tell you there is a lot of money to be made.
At the end of the day, jobs will be lost, families with be affected, and people will have to search for their own answers. But, we just have to keep our heads up and look for that next open door.
Revisiting the Entrepreneurial Rollercoaster
I came across a great article by Cameron Herold guest blogging at Tim Ferriss’s fourdayworkweek.com blog. He writes:
Regardless of whether or not you believe you will ride an emotional rollercoaster running a business, you will. You have two fundamental choices: you can hold on and scream, or you can wave your hands in the air and have some fun.
Also, you’ll find Marc Andresson’s precious nugget of wisdom being quoted as well:
First and foremost, a start-up puts you on an emotional rollercoaster unlike anything you have ever experienced. You flip rapidly from day-to-day – one where you are euphorically convinced you are going to own the world, to a day in which doom seems only weeks away and you feel completely ruined, and back again. Over and over and over. And I’m talking about what happens to stable entrepreneurs. There is so much uncertainty and so much risk around practically everything you are doing. The level of stress that you’re under generally will magnify things incredible highs and unbelievable lows at whiplash speed and huge magnitude. Sound like fun?
I can’t stress enough how important it is to recognize and respect the awesome force that is human psychology as it comes into play during the hectic start-up phase of a company. More often than not, however, setting the right expectations and being informed about your particular industry means you can flatten the so-called “Transition Curve”.
The problem I find with today’s entrepreneurs is that the optimism is often too overbearing. Perhaps it’s the romanticism with which we surround the notion of a “start-up”. Perhaps it’s because people are starting their own companies at younger and younger ages. Perhaps it’s because a lot of tech start-ups are headed by folks who know more about cool technologies than running actual businesses. More likely, it could be because VC money is (or at least was) too readily invested. Whatever it is, the right expectations are not being set to counter-act what Cameron refers to as the “Uninformed Optimism” phase of start ups.
My advice, for what it’s worth, is that you should find something you’re passionate about, persist at it, and do your research.
Usability: Improving the mental model
In his book “The Design of Everyday Things” Don Norman talks about mental models as a way to describe how a system is perceived from a designer’s perspective vs. a user’s perspective. The trick in having an application that feels natural for users is to have those two perspectives be as aligned as possible.
A few weekends ago, when I was conducting usability testing for Ronin, I noticed that the subjects were often clicking the upper-left logo to go home. This is a common paradigm on the web, and it’s often very acceptable to have the upper-left logo act as a “reset”, but I was disappointed in the inefficiency of navigation. For example, for a particular user to navigate to a certain invoice, he would click home, click on the client’s name in the “Recent Clients” section and then navigate into invoices from there. He would also frequently click from one client to another using “home” as a bridge while scanning for open projects. While this didn’t seem like much work (and he pointed to me that he didn’t mind it at all), I felt that the mental model he has established for the application didn’t quite match the mental model I had in mind as the designer of the application.
One problem I identified was that he used home as an entry point because it was the only thing common to all pages - the fact that they were tied to the home page somehow. The lack of consistently available top-level navigation made it impossible for users to develop a deeper, more accessible mode of traversing through the app.
Enter tabs.
Tabs help to establish a clear mental model.
What you’ll notice if you study most applications is that there is always a highly visible interface component that helps users establish a mental model of how to interact with the application. Media players typically have play/pause/stop commands, browsers have back/forward/address-bar, and web applications typically have tabs, or some high-level navigation element.
After adding the tabs in, I found that it helps reassure users of exactly what Ronin is designed to do. It helps scope the application so there is less learning time when a user first jumps into the application. It clearly maps out the high level concepts of “Clients”, “Projects”, and “Invoices” and gives users a consistent anchor to use apart from “home”. You’ll find that these tabs have been implemented into Ronin.
We as humans continually evaluate and reason about the things we perceive. Unfortunately, being subject to so many new ideas and applications means we can only commit a large part of our learnings to standard interface elements and practices. It’s up to the application designer to keep in mind that helping nudge this process along is often means obeying age-old rules of thumb. In this case, it’s “always have visible, clear, top-level navigation.”
