Ecommerce and Entrepreneurship Blog | About | Contact | Store

Suggestions for the Future of Web Design

Posted on February 10, 2010 by Trevor

I am primarily a developer. I like to work on the stuff in the background, the stuff that makes our sites work, rather than what our customers actually see. However, in a small IT department you wear many hats, and I tend to also do a lot of design work. In other words, I'm arranging all of the images, text, and so on that you see when you open a web page. I am sure there are others in the same position so I'd like to give a basic introduction about why design work is so hard, and some possible solutions that I'd like to see in the future.

Designing for the Web

Designing for the web is very different from most other types of design. For one thing, its interactive. The layout and content must change over time based on the actions of the user. More importantly, the layout must be able to change based on the capabilities of the user's system, and still look good. When designing a flyer, you may know that your design will be on an 8.5 x 11" sheet of paper, and it will always look exactly the same. Even movies and video games, media known for their dynamic nature, generally have a few standard sizes and easy ways to transition between them. This is not true for web sites.

There are three standard technologies used to display web content: HTML (Hyper Text Markup Language), CSS (Cascading Style Sheets), and JavaScript (or ECMAScript, to be precise). HTML is the most basic of the three, and displays the actual content (such as text, links, or images) on the page. CSS is layered on top of the HTML, formatting the elements that HTML displays. CSS determines where on a page an image or block of text appears, what color or font it is, and so on. JavaScript is the closest of the three to an actual programming language; it's primarily used for dynamic effects like reacting to user input or providing functionality not available in ordinary HTML and CSS. However, underlying all of these technologies is the actual system running them: the browser. There are many different browsers used to access the web, and none of them completely follows the standards. Each has its own little quirks and extras, which means that in order to display a web page correctly on all of them, a designer must be very careful with what HTML, CSS and JavaScript he uses.

Layout and Headaches like Internet Explorer

Layout is especially aggravating. It uses a very finicky standard to begin with, and browsers tend to take the most liberties with formatting. The primary offender is Internet Explorer, who being by far the most popular browser for a long time, apparently decided it would be fine to throw out the standards and make up their own. Thus the usual method in web design is to get the web page working in all the other browsers, and then do it all over again for Internet Explorer. This has improved in its most recent versions, but a significant proportion of users have never upgraded: we still get over 10% of our traffic from Internet Explorer 6 users, two versions behind the most current. Please, if at all possible, upgrade to the newest browsers! We web designers will thank you.

On top of the browser problem, as I mentioned, CSS itself has some major flaws. CSS is based primarily on "flowing" text layout, as in newspapers and magazines. However, as we know, static layouts aren't a good fit for dynamic web pages, and this model is far too limited to account for the layouts web designers want. This is mostly fixed by a cobbled-on system of layers and boxes, but many of the solutions are obvious afterthoughts. For example, one way to position a box is using "absolute" layout, which means the box is not part of the page flow but lies on top of it in the exact position you specify. This works pretty well, but it's based on the top left corner of the window, so if the browser is resized all the other content moves around but the absolute box stays still. This tends to break things. One way to get around that is to put the absolute box "inside" another box, so that it moves with it. The way to do this is to mark the other box with a "relative" layout, which means that that box stays in the normal flow, but is offset by an amount you specify. There is no logical connection between the outer box's relative layout and the inner box's absolute layout, but the makers of CSS decided that the former was the right way to indicate the behavior of the latter. This is just a simple example.

Changes That I Would Make

However, the situation is unlikely to improve in the near future. Indeed, it would be unwise to do anything drastic about it, because so much of the web is already set up to work as is: and it would cost the economy billions of dollars to make a major change. So web design is likely to remain in the hands of those of us who have experience in its arcane techniques. But if it could be changed, what should it be like? Well, first, I would drop all pretenses at preserving static layout. Similarities to print are analogies, nothing more. I'd make the box model the primary aspect of CSS, with text flow being a subset for use within boxes. I'd rework the relationship hierarchy between boxes to be more explicit with regard to things like positioning. Finally, CSS files tend to be large, flat, and difficult to navigate and edit. I'd like to change that by introducing variables: named styles that can be applied to several different parts of the page at once. There is already something like this (called "classes"), but it's not nearly as flexible as I'd prefer. I believe those changes would make formatting web pages much more intuitive, opening it up to a much larger group of site creators. I do think it's possible to implement these changes, but it would take a long period of incremental changes. In the meantime, I'll be taking on design tasks as well as my more normal development projects.


Kohler is arguably one of the most innovative brands in the home improvement industry. The new Karbon faucet has completely transformed the kitchen and more specifically revolutionized the kitchen faucet. Meanwhile Kohler seems to effortlessly create bathroom fixtures that are not only sleek but save water, like the Escale toilet.

2010 eCommerce Predictions

Posted on January 13, 2010 by Trevor

For an industry that hasn't yet seen its twentieth birthday, every year brings new changes to the web. And at the beginning of every year, people try to predict them. 2010 will surely bring significant new developments to the web, and here are my predictions for a few of them.

"Web 2.0" will be synthesized with traditional sites

The big buzzword a few years back was "Web 2.0", a new set of technologies that enabled users to interact with servers and each other through dynamic, real-time media. Embedded video, social networking sites and AJAX all helped to transform the web from a library of text and images that users passively viewed, to a collaborative sharing of information. However, for the most part these groundbreaking new technologies have been kept distinct from traditional methods, resulting in a partition between "Web 2.0 sites" and ordinary websites. However, the novelty of Web 2.0 is wearing off, and we are starting to get a handle on which of these new technologies will be useful and where. I predict that these trends will lead to a breakdown of these barriers as better tools, APIs and general understanding of the technologies allows more websites to provide Web 2.0 features, and existing Web 2.0 sites mature past the stage of using them as gimmicks to draw people in.

The mobile web will become commonplace

Fifteen years ago, cell phones were the toys of businessmen and the well-off.

The original cell phones

Then, within just a few years, they became commonplace, to the point where a significant number of people don't even have land lines anymore. Today, a similar revolution is taking place in the move from cell phones to "smart" phones. As more people move toward phones that browse the web (and plans that support it), developing websites that work well on the limited hardware of mobile devices will become more important. Phone capabilities are echoing those of the personal computer in the 1990s, migrating from text and voice connectivity to full multimedia support.


Smart Phone Droid

Social sites like Twitter showed the viability of this model last year; this year I expect the mobile web to explode onto the eCommerce scene as people begin to make purchases with their phones. As usual, eCommerce websites will scramble to provide smooth, convenient purchase paths to take advantage of these "impulse buys".

Standardization will finally take a step forward

Developers have waited for years for the unfortunate legacy of early browsers to disappear. These old versions each displayed web pages according to their own interpretations, requiring the developer to write special code for each browser. Newer browsers are more standards compliant, all displaying web pages in the same standard manner. However, older browsers (especially Internet Explorer 6) have still contributed a significant percentage of visitors. Until now. A combination of the proliferation of browsers (especially the success of Firefox and Chrome), the favorable reception of Windows 7, and a concerted campaign to get rid of IE6 has cut its share of visitors in half last year, to a point where it is on the cusp of irrelevance. If that trend continues this year (and there's no reason to believe it won't), by next year we will see a web virtually without incompliant browsers, freeing developers to improve site performance and include standard features of the newer browsers.


For the best prices, on the largest selection of faucets, from your favorite brands like Kohler, Danze, and American Standard shop 24 hours a day, 7 days a week.

Go, Speed Tracer, Go!

Posted on December 9, 2009 by Trevor

Google released their newest gadget for developers yesterday, called "Speed Tracer". It's a plug-in for Chrome's brand-new extension system that purports to show developers exactly where their pages (or web applications, as Google emphasizes) are slowing down.  Its run much like any other trace application: open your site in one window and the tracer in another, hit "record", and go about your site performing standard tasks. Speed Tracer will capture data from your site, process it, and display statistics and details for your perusal.

The central feature of Speed Tracer is the "timeline", a graph that shows how "busy" your browser is: presumably 100% would mean that your browser was entirely consumed processing the site, and thus unresponsive to the user. Sections of this timeline are highlighted and displayed in the details pane below, with information on the events causing any slowdowns. You can also view tips or "hintlets" that give advice on how to improve performance.


Speed Tracer on

So much for the tool itself; now, how does it fit into our toolbox? If you're a developer for a standard web site, unfortunately the answer is "not very well". Google is clearly targeting web applications rather than standard web pages with this tool. The main feature of Speed Tracer, the timeline, is somewhat helpful in visualizing the workings of the page, but it's really geared toward ongoing AJAX-like events and performance over multiple pages. For precise page load monitoring, other tools like Firefox's Firebug and the standalone Fiddler utility do a better job of pinpointing event dependencies and bottlenecks. The hintlet system is another disappointment, producing limited and unreliable data (my colleague received no hints at all, and I was only able to pull up a confusing list of hints on one or two of the topics that Google's Page Speed plugin for Firebug already displays).

However, Speed Tracer is not without its uses. For a quick head's up on page performance, the timeline makes a good visual, and if you plan to develop a web application many features could prove useful. For general web developers, though, Speed Tracer will probably be relegated to a subsidiary role next to your main workhorses. This is Google, however, and there's a good chance they'll be adding features and improving the interface, which could turn this tool into a first-class performance tuning device.



Little Giant has been hard at work engineering pumps that their most loyal customers have been waiting for. is your destination for the new Little Giant TSW Sump Pump System and their NXTGen Condensate Pumps.

The Droid and Business: First Impressions

Posted on November 13, 2009 by Trevor

The big new thing in technology right now is the Motorola Droid with Verizon Wireless. With Google's Android 2.0, Verizon's coverage, and some nice hardware, it's set up to rival Apple's eight-hundred-pound gorilla, the iPhone. Ushering in a new set of smartphones based on smart user interfaces and open development, it's definitely a great phone for technophiles and power users. But how does it handle in a business environment? We got our hands on one, so let's see how it works.

The first impression of the Droid is that it's solid. Weighing in at 6oz (169g) and sporting a minimalistic metal case, it looks and feels like a brick. That may be a turn-off if you prefer your phones to be light, but it's reassuring if you prize durability. It takes up surprisingly little space given its screen and keyboard. Its edges look sharp, but feel comfortable in the hand. You may have heard reserverations about the keyboard, but it's actually quite responsive and easy to use. The plain layout helps when looking for symbols.

The user interface, of course, is extremely responsive. All the little touches that we've come to expect from a top-end modern smartphone are there. The high-resolution screen really shows its stuff, with beautifully sharp and clear displays on maps, websites, and other image-intensive applications. The display is bright and visible, indoors and out.

So, how does the Droid do in a business environment? The most important aspect is probably connectivity. The Droid natively supports Gmail, standard IMAP & POP3 email, Web browsing, SMS messaging, Google Talk, and of course phone conversations. The interfaces for each are well-designed and easy to use. Verizon's coverage is a definite plus here, giving fast, consistent connection to all of these services in most metropolitan areas. Android provides smart switching to wireless hotspots to help keep costs down. Visual Voice mail is a free upgrade, but incurs a small monthly fee from Verizon. Other syncing features include Exchange and Google calendars. Contacts do not automatically sync with Outlook (they do with Gmail and Exchange), but you can import them into your Gmail account relatively easily. This is a general principle with the Droid: Google apps are definitely given preferential treatment in terms of native capabilities. However, it's likely there will be an app available in the Android Market for any major third-party software. Internet browsing is quick and straightforward; it's probably the closest experience to browsing on a computer that's available in a smartphone. It doesn't come with Flash support, but Google promises an update to provide that capability in 2010.

The Droid appears to be best suited for a small business environment. If your business already embraces the Google Apps platform, the Droid should fit in neatly. If you are using other proprietary software, it might be a bit more of a hassle; you'll have to weigh its capabilities against that discrepancy. The Droid prizes user empowerment above other considerations, so it may not be the best choice for large organizations where security is an issue. However, it shines at speed and flexibility, two important attributes for small businesses. Another consideration is that many of its capabilites are overpowered for the typical user's needs; this phone would be best suited for your IT department and mobile professionals, while many employees would be better served with a more basic phone that supplements their desktop solutions. In some cases it might serve as a low-end laptop replacement, but consider your users needs carefully before taking that step. Compared to the iPhone, the Droid probably provides superior business capability, primarily because of Verizon's availability over AT&T, so if you're trying to decide which to upgrade to, the Droid is a good bet. However, if iPhones are already integrated into your business, it's probably a good idea to hold off on switching until the Droid shows a clear advantage.

The Droid's professional style and stunning display ensure it fits in any business setting.


Image of Droid View from Angle 1


Image of Droid View from Angle 2


Image of Droid View from Angle 3


The Droid's 5MP camera has good resolution, but is fairly fuzzy in low light. Expect picture quality similar to that of a digital camera half its size.

Picture take with Droid


Kohler is arguably one of the most innovative brands in the home improvement industry. The new Karbon faucet has completely transformed the kitchen and more specifically revolutionized the kitchen faucet. Meanwhile Kohler seems to effortlessly create bathroom fixtures that are not only sleek but save water, like the Escale toilet.

The Correlation Between Automation and Decline in Common Sense

Posted on September 24, 2009 by Trevor

As a developer, I'm always looking for ways to make people's jobs easier. If I can automate a repetitive task in order to help us get more done, that's usually great, but every once in a while it can come back to bite you.  There is a point when automation can lead to the detriment of basic logic.

healthBase is a sort of health-oriented search engine. It's powered by a technology called NetBase that combs the web for information, flagging and extracting relevant information based on the semantics of a sentence. Sounds good, right? You can look up treatments for a headache,  or pros and cons of Tylenol. You can see it's not perfect, but it does seem to have the right idea.

However, while healthBase's search algorithm seems acceptable, they unfortunately forgot or didn’t have the resources to put any sort of filtering on the results. This can produce some hilarious misapplications. Want to know what treatments there are for Obama? They've got that covered. How about the causes of rap? Or the pros and cons of vampires? Feel free to experiment yourself; these are some of the tamest results.

We can all laugh at those results. But what about when people are actually searching the site for medical advice and the wrong results are returned? What if someone is searching for treatments for Appendicitis, for example, for which immediate surgery is the only proven treatment? HealthBase returns a whole list of treatments (including things like licorice!), which could lull a reader into thinking surgery is only one of several options. Or how about the pros and cons of suicide, at the top of which is listed "provide relief"? While it's true that you can click the "+" button next to a phrase and read the scrap of text from which it's extracted (often entirely out of context), the fact remains that the lists themselves are in some cases dangerously misleading.  I mean they can use the “Beta” excuse but that will only last for so long.

There are two key differences between an automatic process and a human: the automatic process is much faster and easier, but a human has common sense. Both need to be taken into account when considering automating part of your business. If you do decide to automate something, be sure to test and test again, and the more vital the application is, the greater the depth and breadth of your testing needs to be. At Gordian Project, we try to balance automation for speed and convenience with a human element for sanity and a personal touch.  Surely no one here, which I know of, promotes Nazis, but surprisingly healthBase managed to find a whole list of pros:

Pros and Cons of Nazis according to HealthBase



Little Giant has been hard at work engineering pumps that their most loyal customers have been waiting for. is your destination for the new Little Giant TSW Sump Pump System and their NXTGen Condensate Pumps.

Four Profitable Reasons It’s Advantageous to do Good

Posted on August 19, 2009 by Trevor

I recently took a trip to the Philippines where I had the opportunity to help out at an orphanage as well as working on some philanthropic construction projects. Although the work I was doing was hard and repetitive, I had a great time and was able to maintain my energy and enthusiasm throughout the trip. Once I returned, I started thinking about the causes and effects of that experience, and how they could be applied to a business environment.

Most people want to do something worthwhile with their lives. Few people are content to simply work for a paycheck they spend on themselves. Many people choose to donate their money or volunteer their time to a cause they support, and even those who don't, often feel they should. Doing good makes us feel good, and helps us stay enthusiastic and focused. In the same way people spend their personal resources, they also react to their jobs. People want to do a job that's personally fulfilling, a job that accomplishes something worthwhile. Of course, not all of us can work at a philanthropic organization. However, we can still be doing something meaningful even if that's simply making the world a better place by leaving our customers satisfied. In college, I was the leader of a team of people who did, essentially, janitorial work. This was not a glorious job. However, I emphasized to my team that our job was to perform an essential service with superior quality, and the policies and goals I set reflected that. Because of that, my team maintained consistently high morale and an excellent service record.

Another phenomenon both experiences taught me was the benefit that doing good gives to team interaction. People that work together on a project they believe in tend to have higher camaraderie and work together more efficiently. This probably has several causes: they are inevitably like-minded people drawn to the same cause, and they receive positive reinforcement as they see each other playing out the individual benefits I mentioned above. People who are enthusiastic and enjoy what they do tend to like and work well with others who do the same, additionally gratification in assignments will drive focused attention to the project, all of which increase efficiencies.

All of this is fairly straightforward: it's no secret that we want our team members to care about what they do. But it is one thing to want something and quite another to have it. How do we instill this atmosphere in our business? The first and most important step is to have a business worth believing in. That means your goal has to be to provide superior goods or services that actually help people, not simply to make money. Secondly, you must clearly show your team members how your business does that. Third, they need to know their place in the system and how they contribute. Finally, they need to have active participation in improving the process. When team members believe that their active participation has a real positive effect in the world, they'll naturally gain that enthusiasm that helps them do the best job they can.

For the best prices, on the largest selection of faucets, from your favorite brands like Kohler, Danze, and American Standard shop 24 hours a day, 7 days a week.

Evaluating Google Wave

Posted on June 4, 2009 by Trevor
As an ecommerce company, we like to use web solutions. Obviously, the big player in that arena these days is Google. We use products like Gmail and Google Apps to help us communicate and Google Analytics to help us with our business. There are a lot of advantages to that (and some disadvantages as well, of course), but that's not what I'd like to discuss today. Instead I'd like to talk about the big news in web applications today: Google Wave. Google Wave is billed as the next generation of internet communication: as opposed to email and instant messaging--which are essentially based on traditional methods of communication (mail and telephone)--Google Wave was built from the ground up to take advantage of the specific capabilities of the internet.

Now, there's a lot of hype surrounding this launch: Google Wave is claiming to revolutionize communication and collaboration on the internet. It's likely that not all of it is justified: communication has already come a long way and there are other applications that include similar elements. Google Wave is more of a major iteration than a paradigm shift. Furthermore, the best improvements in communication are more likely not to be noticed; the whole point is for the technology to get out of the way and let people do what they want. So flashy widgets aren't usually as useful as simple interface optimizations like faster load times or making the user click less. However, there are a lot of advances in Google Wave and definite reasons to look forward to it.

So, what is Google Wave? For a complete rundown, watch the video below; however, here's my take on the application: The major advance Google Wave makes is to simultaneously support both real-time and cached messages. That is, you can immediately see changes people make, but you can also come back later and see what people have done in your absence. Now, there are "whiteboard" programs that allow multiple people to work on the same document, and it's possible to store the results for later viewing. But Google Wave fully integrates these functions, such that every message is saved. That means it caches (and you can review) not only the final document or given save points but every step in the process: if someone had a good idea that you overwrote but changed your mind about you can just step back through the changes until you find it and then insert it back into your current workflow. This fits in well with Google's "never delete anything" philosophy and allows for much more flexible collaboration. In addition, don't minimize the importance of tying this in to the rest of Google's platform, which will allow changes of all types (text, pictures, Google searches, web pages and widgets, and most likely things like maps and graphs as well) to be added. This allows communication to be much more unified, rather than requiring documents to be spread across different technologies.

Should your company use Google Wave? Well, there are a lot of advantages: increased productivity on collaborations, the possibility of remote meetings, a more unified document platform, and so on. There are possible drawbacks, however, that need to be considered before fully signing on. First, as Spiderman says, “with great power comes great responsibility”. There's no mention of any corporate structure to Wave collaborations: any member with access to the Wave can change anything. Now, the changes are of course cached, so it is possible to go back and undo any changes made in error, but it might not be caught before the damage is done. So it's important that all of your users are mature and knowledgeable about the technology, and I'd recommend you put in place some policies about what should and should not be edited. Not only that, but you'll have to examine even more closely those documents that you plan on making public: obviously allowing the public edit access to your documents carries with it certain risks. Hopefully Google will be adding features that address these enterprise needs, but however it turns out be sure to comply with industry standards. Second, beware of overconfidence; Google Wave will not suddenly allow all your members to be clued in and harmonized on everything. It's just as easy for miscommunication (or even misdirection) to take place here as in any other conversation. Finally, of course, you'll need to think about transitional costs, both in training and migration from existing platforms. However, those things said, Google Wave is an impressive new piece of technology and we at the Gordian Project anticipate trying it out ourselves.


Little Giant has been hard at work engineering pumps that their most loyal customers have been waiting for. is your destination for the new Little Giant TSW Sump Pump System and their NXTGen Condensate Pumps.

Cross-browser Compatibility: Firefox, Internet Explorer, Google Chrome, and Floating Boxes

Posted on May 13, 2009 by Trevor

I try not to discuss technical subjects in my posts because, being a developer, I understand that most of the stuff I find fascinating just wouldn't be interesting to most of you. But sometimes I run across something that's both useful and understandable, and I have to share it. So I hope you'll bear with me.

Cross-browser compatibility is a major headache for web developers. The web is built on standard protocols like HTML, CSS and Javascript. This is great, because it allows all sorts of different computers to communicate with each other. However, there are many different browsers out there to interpret these standards: Internet Explorer, Firefox, Safari, Opera, Chrome, and many more. And each of these browsers comes in multiple versions. And every version of every browser interprets the standards a little differently. Sometimes that's because the standards aren't clear, but usually the browser is simply in error, or a decision was made not to support the standard. So instead of being a simple job of following the standard when developing web sites, a web developer has to consider the unique behavior of the most common browsers to make sure most users see the website correctly. Usually this is done by developing in a more "standards-compliant" browser and then trying to fix the quirks in other browsers while not accidentally introducing any in the original. It's a balancing act that involves a lot of knowledge of the browsers' inner workings.

Troubleshooting Browser Errors

So, I ran across a strange bug on our website,, that I knew immediately was a browser problem, but hadn't seen the problem before. There were several "divs", or blocks of content, on a page that were displaying differently in different browsers. In Firefox and Internet Explorer, the page looked something like this:

div content displayed in IE and Firefox

However, in Google Chrome, the page looked like this:

div Content displayed in Google Chrome

Obviously, Chrome was displaying the page differently than the others. To understand why, we have to dig into CSS, the standard web language that dictates how pages are formatted. CSS works hand-in-hand with HTML: in CSS, HTML elements are given attributes whose values determine how the elements are formatted. For example, you could take some text in HTML and use CSS to make it bold. In this case, the first div (in red) has a CSS attribute called "display" that's set to "inline-block". That means that the div acts like a solid block, that doesn't wrap or change shape because of things around it, but that it also stays inline, so that if there's text around it, it fits right in as part of the text. We'll revisit this later. The second (blue) div has an attribute called "float" that's set to "right". This means that instead of simply being inserted into the text of the page, the div gets attached to the right side of the page (or the section it's in), and the rest of the content flows around it. The third (green) div has no special attributes associated with it; it's just there to illustrate page flow.

So it looks like what's happening is that the first div is forcing the second div down in Firefox and Internet Explorer, but flowing around it in Chrome. Let's do some tests to find out why. First, let's get some text in there to see better how the content flow works. Here's how Firefox looks:

Content in Mozilla Firefox

As you can see, the first div is right in the content flow where it's supposed to be, and the second div is sitting on the right as the content wraps around it. Looks good so far. Here's Chrome:

Content Google Chrome

This looks pretty much the same except for one subtle change. The second div is one line higher than in Firefox. Why is that? I've colored the text to demonstrate. The black text is all before the floating div. The blue text is actually after the floating div, but since the div floats, it wraps around it so it looks like it comes immediately after the previous text. So the difference between the two browsers is this (and this is important, so I'm setting it out):

In Firefox and Internet Explorer, a floating div floats below all previous content. In Chrome, a floating div only floats below content that is directly above it.

W3C (Wide Web Consortium) Standards

So, which is correct? For that, we turn to the World Wide Web Consortium, W3C, the standards body that determines the specifications for CSS. Now, just as there are several versions of each browser, there are also several versions of CSS. The main version of CSS in use for some time has been CSS2.1, but recent browsers have begun adopting parts of CSS3 (which is itself still in development). However, for our purposes they are identical. They give these rules for positioning floats:

4. A floating box's outer top may not be higher than the top of its containing block. When the float occurs between two collapsing margins, the float is positioned as if it had an otherwise empty anonymous block parent taking part in the flow. The position of such a parent is defined by the rules in the section on margin collapsing.
5. The outer top of a floating box may not be higher than the outer top of any block or floated box generated by an element earlier in the source document.
6. The outer top of an element's floating box may not be higher than the top of any line-box containing a box generated by an element earlier in the source document.
8. A floating box must be placed as high as possible.

Those rules are somewhat technical, but the two most important ones here are six and eight. Rule six says that a floating div can't be higher than any line of content that came before it. Rule eight says that, unless another rule conflicts, a floating div should be as high as possible. So, looking at the pictures again, it looks like Firefox and Internet Explorer both line up with the bottom of the previous line of text, whereas Chrome lines up with the top. That means that Firefox and Internet Explorer violate rule eight; Chrome is indeed in the right.

However, now we need to know what to do to fix the issue so that all the browsers display the same thing. There are two ways to do this: we could fix Firefox and Internet Explorer to display correctly, or we could "fix" Chrome to display the same as the other browsers. In this case, I actually wanted all the browsers to put the floating div below the first div rather than to the side, so I chose the second option. My fix was to change the first div from "display:inline-block" to "display:block". This took it out of the content flow and pushes everything after it to the next line, like so:

All Browsers with floating div below the first div

That includes any floating divs below it, so now the second div is positioned the way I want it (as in the first picture) even in Chrome. Since there wasn't any text on the page in that section, it didn't interrupt the content flow. If there was text there, I would have had to find a way to keep the first div as "inline-block" while pushing the float down; possibly by moving the floating div itself lower in the content flow.

If, on the other hand, I had wanted to make Firefox and Internet Explorer work the way Chrome does, allowing the floating div up beside the first, I would simply have to move it to just before the first div in the content. That way it wouldn't be below the div at all: it would be first, and the div would "wrap around" it by staying to its left. Both solutions are relatively easy once you understand why each browser is behaving the way it is, but it took some digging to do that. I wasn't able to find anyone else detailing this discrepancy, so I hope this post is helpful to you web designers out there, and for the rest of you, chalk it up as a glimpse into the life of a developer.

The possibilities are endless with a bathroom remodel. Discover your classic side with a clawfoot tub, experiment with fresh bathroom vanities and coordinate it all with matching faucets. Shop 24 hours a day, 7 days a week for all of your bathroom needs.

Recovering from a Serious Website Error: Four Simple Steps

Posted on April 29, 2009 by Trevor

Oh no. It's happened. I was making a fairly ordinary update to one of our eCommerce websites. I had tested it pretty thoroughly and gone through the whole procedure of preparing it for launch. I held my breath and launched it-- and got an error screen. I refreshed the site homepage, and my heart sunk. The site, the entire site, was broken. We lose literally thousands of dollars an hour when the site is down, so this was a huge deal.

As a developer, what do you do when something goes very, very wrong? You're not expecting it: you may have prepared for it but you didn't believe it would happen. And now it's staring you in the face. And depending on how you handle it, you can either recover quickly with minimal losses or you can flounder and make it even worse. Here are a couple of points I've learned that can help avoid the latter.

  1. Calm Down - I can't tell you to stay calm, because you probably lost that when things started going wrong. But you can calm yourself, and you're going to need to if you are to respond properly. Rash mistakes can easily compound the problem, making it many times harder or even impossible to recover from. So take five seconds, sit back, breathe, and tell yourself, "OK, this is bad, but panicking would only make it worse. So I'm going to be careful and do things right." Then just follow through, solving the problem as you would any other. The urgency of the situation is useless in helping you solve it, so forget about it. You'll be more likely to see solutions you otherwise wouldn't, and less likely to miss further dangers.

  2. Be Honest - Your first impulse may be to try to cover up any mistakes you made or anything that could lead blame to fall on you. However, your first priority is to fix whatever's gone wrong, and that often runs directly counter to that impulse. The first step to solving a problem is figuring out exactly what the problem is, and that can't happen if everyone involved is afraid to release any information in case it might inculpate them. Remember that you need to be honest with yourself, as well. Don't try to convince yourself that it wasn't your fault or it's not that bad if it was or is. This is also a management issue: managers should make it clear in their policies and behavior that, while subpar performance isn't acceptable, no one will be punished or scapegoated for owning up to their mistakes (my own managers were very understanding!).

  3. Look Forward - Computers are (usually) programmed to obey logical rules. They perform the task given to them, exactly as it is given to them. They don't worry about things like pressure or situation. Humans, however, aren't made that way. We have emotions and operate, more often than not, on general heuristics and hunches rather than logic. This is good in many cases; we can do more with less than computers. But in certain situations it's a problem, and one of these comes up often in crisis situations. One of our rules of thumb that we tend to follow is that if we've already invested ourselves in a certain course of action, we try to protect that investment and, if necessary, follow it with more. Unfortunately, if it's a bad investment, we end up "throwing good money after bad", losing more and more while becoming more and more attached to one course of action. This shows up in crisis situations when we get fixated on one course of action, trying more and more variations on the same ineffective theme. We can even end up stupidly repeating the same action over again, hoping that this time it'll work. Instead of doing this, try to forget about what you've already done and think instead about where you want to go. When making a change to a website, for example, I might be tempted to think, "Well, since we've already put the changes on the site, we should try to fix those changes." However, my immediate priority is to get the site working; if it's faster to do that by undoing all my changes and going back to the original version of the website, that ought to be my course of action instead.

  4. Be Lazy - This one may surprise you. Being lazy isn't usually thought of as a good quality, and of course I don't mean that you should be slow and unwilling to do the work needed to fix things. However, there is a place for laziness in being smart about your time and effort. Let's take an example to clarify. Suppose I've got a problem that has two possible solutions. There's a 90% chance that I need to undo all my work, figure out what the problem is, fix it, and put it back in place. However, there's a 10% chance that all I have to do is re-apply my change because it got corrupted the first time. My initial impulse might be to go the undo-and-fix route. However, if I'm smart and lazy, I could realize that I could at least try the other option. Even though it's less likely to fix the problem, it takes an insignificant amount of time and energy. That way I'm more likely, in total, to get the problem fixed sooner.

That last point actually turned out to be the case when the site went down on me. While I was starting a large roll-back to a backup version of the site which would require a lot of cleanup, someone else suggested simply restarting the site on the server. That turned out to be the problem, and it was back up with a minimum of downtime and cleanup work. While I learned that point the hard way, I plan to keep all of these in mind in the future.

Kohler is arguably one of the most innovative brands in the home improvement industry. The new Karbon faucet has completely transformed the kitchen and more specifically revolutionized the kitchen faucet. Meanwhile Kohler seems to effortlessly create bathroom fixtures that are not only sleek but save water, like the Escale toilet.

The Importance of Documentation in the Workplace

Posted on April 7, 2009 by Trevor

Documentation, the recording of organizational structures, policies, actions, and goals, is vital to any business, and doubly so for those of us in development. When I came on board I inherited roughly 200,000 lines of code that I had to learn well enough to find and pinpoint individual errors, within the span of about a week. While experience and clues from within the code help somewhat, the job would be nearly impossible without documentation of some kind. And documentation will continue to be important going forward: with so much to manage, it's unlikely I'll remember exactly what a particular piece of code does even a few months down the line unless I leave some easily understandable record. Even outside of the development world, documentation plays a fundamental role in business. It codifies procedures, ensuring everyone in the company does things the same way (hopefully the right way!). It streamlines processes, allowing people to look up answers instead of asking coworkers or reinventing the wheel. And it acts as protection during audits, helping to pinpoint any actions taken against policy. So, how should documentation be developed and integrated into your business practices?

First, it's important to develop your documentation alongside the actual process. Too often developers take the attitude, "Code first, document later." That would be fine if we could stick to it. But in practice it tends to become, "Code first, then code something else, and put off documentation for another time." Instead, you have to consider documentation a priority, updating it while the work you've done is fresh in your mind. Will that make you work slower? At first, yes, but over the long run it should save you time. Instead of thinking of documentation as something that hampers your real work, consider it as part of that work. You can't set aside part of your job because it's slowing down another part.

Second, streamline your documentation process to require the least amount of extra work. It's especially important not to duplicate information. When I'm documenting code, for example, it's often possible to intersperse the code and the documenting comments so that half of the documentation is the code itself. That way I'm not duplicating information by writing it once in code and once in the documentation. Another possibility is to set up automatic documentation procedures, so that you only need to manually fill in specific information. I have a Google document to record changes I make: it automatically fills in several fields for me, and other fields are set up to ease entering that information. This took a bit of extra effort to set up at first, but it reduces the ongoing work.

Third, be sure to structure your documentation. If you're documenting your work as you do it, it's likely that the documentation will be close to the actual work, both in detail and in location. That is wonderfully helpful when you're already looking at a specific piece of work, but what if you're trying to find that piece among all the rest? For that, you need higher-level documentation that gives the general structure of your work, explaining each piece and where to find it. It might also be helpful to give pointers to this general documentation from the specific pieces so you will be able to follow it back. However you choose to do it, make sure that your documentation gives a clear starting point to someone who doesn't already know what they're doing. Hunting for the right documentation is often just as frustrating as trying to understand the work itself.

As I come to grips with the code I have to work with and the duties I'm expected to perform, I'll be reading, updating, and creating the documentation to go with them. I'm hoping that with these principles I can efficiently create documentation enabling me and anyone else who reads it to get up to speed quickly and get the work done.