Opera is 15 years old! I first started using the browser back in 1997 or so when I was working at OU doing support and web design for the financial departments there. I had gotten interested in web design in 1994 or so and was completely self-taught, but I had become interested in CSS and standards as soon as I’d learned about them. After I moved here to Norway in 1999 and was looking for a job, I checked out Opera’s website for job opportunities, and lo and behold, they were looking for a webmaster. I applied and had an interview with Jon and Håkon. They seemed to be impressed by my code, which was a major ego boost for me, given who they were and what they represented.

I got the job. I think I was their 26th employee. I was 22, and I felt like my career was really getting off to a good start—this was just the kind of work I wanted to do, and Opera was really the place to be for someone interested in standards. It still is! It was a really fun, informal environment and I enjoyed working there.

Just a few months thereafter, however, my grandmother died, and I fell into a seriously disabling depression. I was on sick leave for a year, and tried to come back to work after that on “active sick leave”, but didn’t manage to make it work out, so I had to quit. That’s still upsetting to me to this day, almost 10 years later, as I see the direction they’re gone in and how it still mirrors my interests in usability and standards. It was such a missed opportunity. I’m trying to get back into the workforce now, but I don’t think I’ll ever have the chance to make a difference as I might have had working for Opera.

After Firefox, and after Chrome, people have been quick to predict Opera’s demise, but I don’t see that happening anytime soon. Opera’s rock-solid grounding in and commitment to usability and standards—both on desktop environments and other platforms—ensure it a place in the game for a long time to come. Their research in these areas and promotion of these values is still sorely needed. Here’s to another 15 years—I look forward to seeing what they do next.

I’ve learned an important lesson the hard way this year: addressing a problem too generically is setting yourself up for failure.

I don’t consider myself a programmer, but given who my husband is, I’ve been steeped in agile philosophies for nearly a decade, and most definitely consider myself a proponent of such ideas. I can see how they can be applied to almost any aspect of life, but I was really looking forward to giving them a whirl when I took a contract earlier this year that I’d decided to solve using JavaScript. The script ended up being a lot more work than I’d expected, and while it worked perfectly, the amount of DOM interaction it required made it entirely too sluggish to be practically useful. In the end I had some ideas about how to speed it up, but since I’d been working on a fixed price (something Johannes had thoroughly castigated me for) I figured it was best just to deliver it how it was.

Why did the script end up being so much work? I’d been hired to do a specific job–to adapt tables in a web application to fit the size of the viewport, with the table header remaining fixed while the table contents scrolled if the table was too large to fit within the viewport. In order to do that, I’d set the scipt up to gather information about the original table, process it, then write the new, adapted table into the document.

The stupid decision on my part was the first part of that equation: gathering information about the original table from the document. Stupid because, in an earlier contract, I’d been the one who styled the original table in the first place! Without even having thought about it, I’d defined the problem too generally. My job had not been to create a solution to turn a standard table into a fluid one. My job had been to turn those specific tables into fluid tables. If I’d been clear-sighted enough to solve that problem in the first place, the script would have taken a lot less time and have (hopefully) been fast enough to be usable.

The problems we’re given are specified by the existential quantifier (∃), not the universal quantifier (∀). Theoretical and practical aspects of falsifiability are addressed in computer science classes and tied to real-world examples, right? From talking to Johannes I’ve learned that defining the problem too generally is frequently a problem for developers, however. I think people somehow feel it’s cheating to solve a problem only for specific circumstances. In reality, it’s the only thing that’s possible. We can save a lot of time, energy, frustration, and cash if we keep that in mind.

Bugzilla@Mozilla Bug 442542: Position:absolute elements will not move when window is resized if a sibling contains float elements and a clear:both element

For once wacky CSS behavior is due to a browser bug and not a misunderstanding of the CSS spec (by me or the people writing the rendering engines).

The website for Smidig 2008 went live last night. It’s not without its bugs, but I’m proud of the design job I did.

Check out this interesting comparison of product packaging photos vs. the appearance of the actual products.

I just updated Romerike Helsebygg’s site with a bunch of new images Bjørn sent me. These new images are incredibly inspiring, although not as inspiring as getting to see the construction progress every time I take the train into Lillestrøm! I’m also happy to see that my site design has held up well these past five years.

A while back someone asked me to design a site with all sorts of gradients and crap. I think that a “Web 2.0″-look was even specifically requested. The request gave me indigestion, and here’s why:

| View | Upload your own

Johannes and I bought a Samsung CLP-510N color laser printer for our company a couple of months back. This model can run as a network printer, but you have to buy a special replacement network card for the printer if you want the printer to be able to access the network wirelessly. Fine, but the network card for the printer costs about two-thirds what the printer itself costs. Ridiculous!

Wires are annoying, though, so I thought a good solution would be to install a wireless ethernet adapter for the printer. The wireless adapter cost a third of what the network card would have cost. The ethernet adapter I bought, the Belkin Wireless G Gaming Adapter, had several reviews talking about how easy it is to set up. I went ahead and bought it.

Today I went to set up the adapter. I started following the directions on the quick-start guide in the box. I connected the adapter to the wireless router and started the software, and was greeted with the following image:

“Shit”, I thought. The “next” button was greyed out: the adapter configuration software wasn’t detecting the gaming adapter on the LAN. Not good—since we have a secured WLAN, I needed to connect the wireless network adapter to the LAN first to configure it to access the WLAN. I tried everything I could think of to get the LAN to see the gaming adapter, but to no avail. After about 10 minutes of useless futzing around, I happened to mouse-over the “next” button on the configuration software.

*headdesk*

The buttons were grey, but they weren’t “greyed out” as per Windows UI conventions. Annoyed at having wasted so much time because the UI designer for this software was an idiot, I clicked on the “next” button and had the adapter installed and working in about 10 seconds.

Lesson learned: Making buttons with mouse-overs greyed-out when they’re active but not being hovered over is a very bad idea. Some UI conventions cannot be flouted.

Johannes is making his idea happen: Smidig 2007 is going to be held on November 26th and 27th at DogA here in Oslo. For those who don’t read Norwegian, he has written a little about the conference on his blog.

The night before his JavaZone presentation, Johannes and I had fun making diagrams for some of the slides in his presentation. He had prepared some basic sketches of the concepts he wanted to get across, and asked me to help him transform those sketches into comprehensible drawings done in an informal style. So I whipped out my tablet and went to work.

This was the original deployment sketch:

And this is what I turned it into:

That one was by far the easiest and most straightforward diagram to make.

Here is the original lifecycle sketch:

I turned it into this:

That one took a little more adjustment.

Here is a copy of the original dependency sketch:

Considering the fact that I’m not a programmer and know nothing about this particular subject matter, trying to understand these rather technical concepts, let alone creating a diagram to communicate them, was a complete and total nightmare. Some of the relationships described by the sketch represent processes, and some represent content hierarchies, e.g. the application module contains the WAR file, which contains the business logic; the .zip file is dependent on the assembly plugin, which is in turn packages on the WAR file (into the ZIP file). Some of the items in the diagram are files, some are plugins, and some are modules. Johannes was patient in explaining all this stuff to me. We went through innumerable iterations of “Is this right?”…”No, this arrow needs to point this way.”…”OK, how about this?”… The final diagram ended up like this:

The slides have gotten a lot of positive comments. I’m happy with the results, and I really enjoyed this whole process. I’m glad I got to put to use some of the skills I intend to use if I ever become an information architect, and it’s nice have a better idea of what Johannes is working with in his job.