It is 4:51AM Atlantic time and I am sitting in bed with my laptop on my lap. One minute ago, Ben Goodger gave me the final word and I made this CVS commit to the mozilla.org website:
steven%silverorange.com 2004-11-09 00:50
People of Earth, I give you Firefox 1.0
It’s been a long time coming, but Firefox 1.0 is here. See 1.0 announcement posts on Mitchell Baker’s weblog and Ben Goodger’s weblog.
It is an honour to be a part of this announcement.
Perhaps because I frequent web news outlets with a geeky bent, I’ve seen a lot of negative reaction to Microsoft’s Service Pack 2 update to Windows XP. Much of this criticism is understandable. Microsoft has been pushing the security issue hard, and it will be near impossible for them to live up to their promises.
That said, let’s be fair to Microsoft. They’ve been criticized for a delayed roll-out of SP2 and for a slew of applications that “break” after it is installed. Well, rolling out a major (free) update to the worlds most popular operating system is not easy. The amount of backwards compatibility issues that Microsoft deals with dwarfs that of competing operating systems given their install base. Upgrading the install base of Windows XP is a massive engineering undertaking.
As for some applications “breaking” after SP2 is installed – sure, there may be (and likely) are bugs in SP2. However, much of the “breaking” I’ve heard of is due to new security policies that Microsoft has been criticized for not having in the past. For example, their Firewall is now turned on by default. This will wreak havoc on all kinds of applications (it messed up some online gaming software for me in the past). However, it is a necessary change. Sure, it will cause some annoyances in the short term – but it will make computing safer in the long term.
We can’t criticize Microsoft for shipping an operating system with no firewall turned on by default, then not give them credit when they finally do ship with a firewall on by default.
SP2 probably doesn’t make Windows secure. From my (admitted limited)understanding, there are fundamental architectural decisions that will prevent Windows from ever being as secure as the more network aware alternatives (Linux and Mac OS X). However, SP2 helps – if only a bit.
I now run Linux as my primary operating system. I run Windows XP occasionally, and I updated my XP partition on my laptop to SP2 today. When an application started to load up in the background, XP with SP2 told me about it, and asked me if it was ok for it to run. If I make legitimate software that runs in the background, this will be an annoyance and may make for a slew of calls to my support line. However, it will make it a hell of a lot easier to find all of that spy-ware running on your moms computer.
Bottom line: SP2 will help make home computers a little bit less annoying for our families to use. I think Microsoft deserves at least a bit of credit for that.
It’s up! The new design for Mozilla.org by Daniel Burka, myself, and the others here at silverorange, working with the brilliant and patient people at the Mozilla Foundation has just gone live.
Here’s the CVS checkin:
dbaron%dbaron.org – 2004-08-31 14:31
Landing BETA_20040721_BRANCH: new template, homepage, and product page design by Steven Garrity and Daniel Burka from silverorange, and required tools changes by Myk Melez.
Be sure to refresh! Thanks to all involved (especially bart, dbaron, and myk).
Of course, there is still lots to do to improve the site, and we’ll keep working on it – but for now, it feels good to be live.
There has been lots of helpful feedback to our public beta of the new Mozilla.org website.
We’ve fixed many of the issues that arose during the beta and we’re aiming to launch the new site tomorrow evening (Tuesday, Aug 31). This is a final call for critical issues before we launch. Feedback can be posted on this MozillaZine thread. Thanks!
The website beta lives at website-beta.mozilla.org.
I was contacted this week by Alexander Klimetschek, who has built on the work of Hal Hockersmith to get finally get out a version 0.3 of the Luna Blue Theme for Mozilla Thunderbird.
My motivation for working on this theme was purely selfish, and now that I’m running Linux instead of Windows, I don’t have that motivation anymore. Fortunately, others have picked up the slack.
This version should work with Thunderbird 0.7.
Download/Install Luna Blue (v0.3) for Mozilla Thunderbird
lunablue-thunderbird-0.2.jar – 703Kb RAR File
UPDATE: Alexander Klimetschek has created an updated version of this theme (Download v0.4) as mentioned in this comment.
I know this won’t make any difference, but it’s worth a shot: I am not maintaining this theme anymore. I’ve just posted it here as a convenient location for people to find it.
The excellent instant-messaging program/project, Gaim, could use a new logo. It would need to be something simple and elegant that works well as a little 16-pixel system-tray icon, as a full-size application icon, in larger spots (login screen, about dialog, etc.) and in other locations with status symbols with the icon (offline, busy, etc.).
Here’s the current Gaim logo dude and a screenshot of a folder that shows some of the other ways the logo is currently used.
Gaim is becoming quite popular as an instant messaging client. It is already widely used on Linux, and I think it could catch on like Firefox on windows too.
I wish I had more time to help, but I thought I’d try to spread the word. If you are interested in helping, join the Gaim-devel mailing list.
Update: It turns out the Gaim guys are still pretty happy with the little one-armed man. Still it can’t hurt to try some new things.
This month in WIRED Magazine’s Wired/Tired/Expired:
| Wired | Firefox |
| Tired | Mozilla |
| Expired | Explorer |
Software is often used in ways not envisioned by its creators. Sometimes this is the goal of the original creation; to create a platform upon which others can create in ways the platform builds can’t even imagine. Some developers build tools and enable others to build. Such is the case with the technologies behind the Internet and the Web. Tim Berners-Lee, for example, is unlikely to have foreseen independent personal web authors covering political conventions (or perhaps he did – I get the impression he’s a pretty smart guy).
Most creations, though, are built with a simple purpose in mind: move a person from point A to point B, playback audio signals transmitted via radio waves, etc. Even more specifically, some tools have a single, even more narrow focus. Even so, such tools are often put to use, for better or for worse, in ways never intended by their creators. We use books to hold open windows, we stir paint with a screwdriver, we use newsprint to get a fire going.
Such is the case with a simple software tool on most PCs. In the corner of the screen (usually the bottom or top right), there is often a little clock. On Windows system, double-clicking (or right-clicking and selecting a menu item) will display a dialog for changing the time/date. This dialog includes a small calendar.
When in front of a computer planning some travel with a friend recently, I noticed that she would frequently double click on the little clock applet of her Windows PC and use this tiny configuration calendar to do quick planning. The Windows Time/Date Properties window (screenshot) is her calendar.
I was struck by how it seemed second-nature for her to call up this window. I recalled that I too had used this time/date settings window for the same reason in the past (What is the date next Tuesday? Is August 5th a Thursday or a Friday?).
I suspect the Microsoft engineers, quite understandably, were not thinking that this window would be used for anything more than setting the date. The dialog doesn’t seem to have changed since Windows 95. However, I’m sure thousands of people use it for for planning and for reference every day.
As part of their efforts to integrate the email/calendar application, Evolution, with the rest of the desktop (via the Evolution Data Server which makes calendar and contact information available throughout the desktop), the Gnome developers are making calendar information from Evolution (meetings, tasks, appointments, holidays, etc.) available in the desktop clock applet. The Gnome calendar is easily accessible in one click from the panel clock, and is just as easy to dismiss when you’re done with it.
This is the type of thing I might have expected Apple or Microsoft to pull off thanks to their strong control over the operating system and popular calendar applications. Instead, it is a small innovation from the open source development world. Bravo to the Gnome and Evolution developers for this smooth bit of integration.
I gave a short talk last fall at the Zap Your PRAM conference about how some of the ideas and technology that have made weblogs so successful can be applied elsewhere on the web. However, the talk was cut short due to a tight-schedule (the conference was run by amateurs – including myself). What follows here is the substance of my talk – some of which I had time to share at the conference, some of which I did not.
What makes a weblog a weblog? Is it the permalinks, the reverse chronological order, the personal voice, syndication? The exact definition of a weblog is an excersize of in semantics that doesn’t particularly interests me. What does interest me, though, is what makes weblogs so engaging and powerful as opposed to standard websites.
First, let us look at some of the key distinguishing features of weblogs when compared to the rest of the web. Note that none involve any kind of real technological breakthrough or innovation. Most a simple adaptations of existing technology.
When examined individually, none of these distinguishing features of weblogs seem particularly interesting or innovative. Most, or all, of these features have been available through one for or another before. However, when combined, they create an environment where people can connect and communicate easily on a variety of scales.
Each of these attributes of weblogs can also be applied outside of the world of websites. RSS feeds can be used to share all kinds of data. I wrote, last year, about how RSS is used on the Sloan band website to syndicate four different types of data.
Amazon.com, for example, has taken great advantage of allowing reader / user feedback (mostly in the form of book / product reviews). Of course, Amazon.com has a “permalink“ for each book – as each book lives on its own page. However, Amazon.com does not offer “permalinks” for reader reviews, which limits the ability of external authors (like webloggers) to interact with the world of Amazon reviews.
I find these basic attributes of weblogs are helpful to keep in mind when developing other website and web systems. This doesn’t mean you should stick an RSS feed on every site you build. Rather, it is helpful to keep an eye out for parallels between the world of weblogs and your project and draw on your experience as a weblog reader and writer.
A look at how Stewart Brand’s classic work of social and architectural criticism, How Buildings Learn, applies to web design and development.
First, if you are in any way interested in design, history, or architecture, which I assume you are by your presence here, read the book How Buildings Learn: What happens after they’re built, by Stewart Brand. Building on Jane Jacobs’ classic criticism of city planning, The Death and Life of Great American Cities, Brand looks at what happens to buildings over the fourth dimension: time.
As I began to read How Buildings Learn, the initial concepts tickled me as familiar in a way that great and simple ideas often do. When written clearly, they seem obvious. However, when we look at the world around us, these ideas are clearly not obvious – or if they are obvious, they are ignored. Further in to the book, the basis for this familiarity becomes more obvious. Idea after idea and concept after concept, clear parallels emerge between the architectural issues dealt with in the book, and those issues we deal with every day as web developers.
Brutally oversimplifying Brand’s premise, he argues that modern architecture and building practises are ignoring what happens to buildings after they are built. Buildings are designed to be impressive on opening day and in 3D computer models, but not to be livable in the long term. When the ribbon is cut on opening day, many architects see their jobs as finished. So too are many websites designed to look good in the portfolio of the designer, no deeper than the front page. They aren’t designed to be lived in – they are not designed to be used, either by the visitors or by those who maintains the site.
Brand’s most fundamental edict is that of building for change. Perfection is a doomed goal. When building, whether it be a house or a website, if you try to freeze time and build for a perfect present (or your own concept of an ideal future), you are damning those that will maintain your creation to work within your flawed construct of perfection. Aware of this pitfall, the time-aware builder puts trust in the knowledge and experience to be gained by the tenants of his creation. He knows that after 10 years of living in a building (or ten months of managing a website), the original builder is no longer the expert. Rather, those who have come to occupy the building will be the experts – having dealt with the thousands of small challenges and decisions that confront an occupant through the years.
One, two, or three years after you’ve built a website, there is a strong chance that someone else will then know a lot more about it than you. They may thank you for your clear foresight in not over-specifying the structure of the site. They may also curse you for choosing a proprietary database or for not documenting your code.
Brand highlights the practises of builder / designer John Abrams as a great example of how to document your design for the next generation of occupants and builders. During construction, Abrams would photograph each wall before it was closed in – capturing the position of all service elements (electrical wiring, stud-spacing, plumbing, etc.). These photos were eventually compiled into a book that was passed on to the owner of the building when construction was finished.
The clearest parallel to this type of documentation in the web world is documenting and commenting of code. Code should be written and documented in a style that intends an audience other than yourself. Other seemingly trivial examples can be a life-saver for long-term maintenance, such as keeping original photo and vector art files or documenting and storing any fonts used in the project.
Brand also suggests that designers and builders use, as much as possible, local materials. Wood and masonry from the locale of the building site is far more likely to be available down the road when needed for repairs and replacement. While exotic masonry or roofing tiles may be an enticing conversation piece, it will turn into a maintenance nightmare when they start to crumble and the next owner of the building is unable to find suitable repair and replacement materials.
As there isn’t really such a thing as ‘local materials’ when it comes to web development, we must abstract the advice: Use materials that will be easy to maintain and build upon in the long run. While much has been said of the long term benefits of standards compliant XHTML on the front end of web development, little has been said of the long term effects of the back-end structure and choice of development platforms. If your site happens to be a collection of static pages, then strict XHTML compliance and careful structuring of code will help ensure long-term access to the content. However, many sites are more like an iceberg, with the generated HTML showing only a hint of of the server-side programming that lies beneath the surface.
In an extreme but brilliant example of ensuring ample maintenance supplies for future generations, Brand tells of a story by anthropologist / philosopher Gregory Bateson [sic]:
New College, Oxford, is of rather late foundations, hence the name. It was founded around the late 14th century. It has, like other colleges, a great dining hall with big oak beams across the top, yes? These might be two feet square, forty-five feet long.
A century ago, so I am told, some busy entomologist, went up into the root of the dining hall with a penknife and poked at the beams and found that they were full of beetles. This was reported to the College Council, who met in some dismay, because where would they get beams of that calibre nowadays?
One of the Junior Fellows stuck his neck out and suggested that there might be on College lands some oak. These colleges are endowed with pieces of land scattered across the country. So they called in the College Forester, who of course had not been near the college itself for some years, and asked him about oaks.
And he pulled his forelock and said, “Well sirs, we was wonderin’ when you’d be askin’.”
Upon further enquiry it was discovered that when the College was founded, a grove of oaks had been planted to replace the beams in the dinning hall when they became beetly, because oak beams always become beetly in the end. This plan had been passed down from one Forester to the next for five hundred years. “Your don’t cut them oaks. Them’s for the College Hall.”
A nice story. That’s the way to run a culture.
Excerpt from Stewart Brand’s How Buildings Learn.
The true architect builds with a clear understanding of the limitations of his current vantage point, before a building exists, rather then blindly ignoring them. When building your next web project, be sure to plant oaks for the next developer.
Building well architected systems with well thought-out directory and file naming schemes and well commented code is all well and good when you have the time and resources. However, what about that little side-project that you don’t really have time to do anyhow? You’re not getting paid much for it, and you don’t have time to do as good a job as you would like.
That’s fine, as long as you keep a few simple things in mind. The method of building and designing that Stewart Brand argues we need is not one of big budgets and over-planning. On the contrary, Brand embraces simplicity, common sense, and frugality in what he calls the low road.
“A young couple moves into an old farmhouse or old barn, lit up with adventure. An entrepreneur opens shop in an echoing warehouse, an artist takes over a drafty loft in the bad part of town, and they feel joy at the prospect. They can’t wait to have at the space and put it immediately to work. What these buildings have in common is that they are shabby and spacious. Any change is likely to be an improvement. They are discarded buildings, fairly free of concern from landlord or authorities: “Do what you want. The place can’t get much worse anyway. It’s just too much trouble to tear down.”
Low Road buildings are low-visibility, low-rent, no-style, high-turnover. Most of the world’s work is done in Low road buildings, and even in rich societies the most inventive creativity, especially youthful creativity, will be found in Low Road buildings taking full advantage of the license to try things”
Excerpt from Stewart Brand’s How Buildings Learn.
Your quick and dirty little side project is not intended to be a monument for the ages. You’re not building the pyramids here – you’re just trying to get something done on time and on budget (if there even is a budget). Brand’s low road of building and architecture is all about quick and dirty solutions. The redeeming feature is that it be quick and dirty enough that you can tear down or dramatically renovate without anyone missing the original.
The second key to building on the quick and dirty low road is to remember that even if you don’t intend something to be used for very long, if may well be.
Architecture is full of examples of hastily built buildings intended for a temporary use living long and fruitful lives well beyond the scope envisioned by their original builders. This phenomenon is sure to be familiar to most web developers; that web site for the university department that you built in an afternoon in 1998 is still up; that sloppy web-based application system you doubted would even work then somehow went on to handle loads of traffic.
We’ve all had projects like these. The next time you go to build something “quick and dirty” or do an ugly hack on an existing system, remind yourself that this code will probably live on far longer than you may intend.
These are only a few of the parallels between Brand’s great work, How Buildings Learn, that can be applied to web development. The book is full of other anecdotes and examples that can help any web designer or developer.
