dan-menard.com

I spent yesterday in Montreal at Make Web not War. It was a really fun time, and I learned a lot of neat things and met some interesting people. I was tweeting about it a fair bit, as were many others, (#webnotwar was actually the top-trending topic in Canada for much of the day) but for the benefit of those of you that don’t follow me on Twitter, I thought I’d sum up the experiences I had while I was there.

The keynote was a good start.

Joel Perras gave a great opening speech that really set the tone for the day. There were a lot of thoughtful tidbits about how closed-source platforms and open-source platforms can interact with one another, but by far the most-quoted phrase from this introduction was the following:

Interoperability isn’t a feature. It’s a requirement.

This simple sentiment sums up exactly what Make Web not War is about. Different platforms must interact with one another to be part of the modern web.

Next I saw a crazy-looking WordPress development process.

Morten Rand-Hendriksen develops WordPress applications, but he does things a little more radically than most people. He uses Expression Web to make presentational changes through a GUI, rather than editing CSS himself, and the speed of results was pretty remarkable. This was a really thought-provoking presentation, and lucky for you, some of the content is available on Morten’s blog.

Morten also shared a bit of interesting WordPress knowledge. Did you know that WordPress 3 (which is currently in Beta 2) will support custom CMS-style menus? The interface for it is very slick; select what you want, and drag/drop to set the order (no more HTML-level changes). Secondly, he found a really neat hack for creating custom template pages per-category: simple add a page called categoryName-categoryId.php and it will be used by WordPress for that category’s landing page. Lots of potential here!

Then there was a really interesting panel about communities.

The panel set-up was very informal, and provided a great atmosphere that really made it feel like we, the audience, were simply listening in on a conversation between the panelists. It’s hard to describe what I liked so much about this particular panel, but from what I remember, the take-aways were something like this:

• In the world of web development, the community is your best friend.
• In order for the community to grow and remain healthy, people have to participate.
• Waiting for the “big” meet-ups that happen every four or five months isn’t good enough.
• All big cities have a variety of technologically-inclined groups that meet up much more often than that.
• The meet-ups don’t even have to be techie; a karaoke group or patio night is just as productive.

So the message overall was pretty loud and clear: get out there and spend some time with others in the web development world, doing anything from talking about new technologies to trading bacon-themed recipes.

After that, there were some five-minute web-app demos.

The one in particular that caught my eye was the not-very-carefully-named Flockoo. This is a service that allows you to log in with your Twitter account and enter a location, and then returns a list of all the users you follow from that location. Very useful for conferences, for example.

My favourite panel of the day was actually about SEO.

Man, was I shocked. I went into this one thinking it would be a drag (I have a relatively low opinion of self-proclaimed SEO-experts) but it turned out to be absolutely full of practical, useful information. The speaker promised that the slides would eventually be available via SlideShare, and I’m anxious to give them a re-read. They filled in quite a few gaps in my SEO knowledge, and I’m sure they’ll help you too.

Next was another panel, this one about cloud computing.

I’m not much of a cloud-guy yet, so I didn’t really gain much from this session. The only thing I distinctly remember was one of the panelists describing the current state of your average cloud-based service as a “cloudsterfluck”, which is a term I’m sure I’ll re-use for months to come.

Then I was pretty disappointed with the HTML5 session.

This is a topic I know a lot about, and I was really looking forward to seeing some interesting demos or cool new techniques. Unfortunately the speaker spent most of his allocated time rambling about spec changes, something that I (a) could have learned about myself in about half that time, and (b) was already intimately familiar with.

He did mention HTML5 Doctor, though, which is a fantastic resource for all things HTML5, and I made a point to share this awesome HTML5 demo with the other attendees via Twitter, as it’s my favourite HTML5 application to date.

The CSS3/jQuery session wasn’t much better.

The material wasn’t quite so dry, and the presenter was much more animated, but there still wasn’t anything really new or interesting.

Finally, there were the Coding Competition finals.

This is where the very best of two-dozen-or-so web-apps were shown off by their developers and voted on by their peers (the other attendees). The criteria for these submissions was that they used PHP, open data, and/or Microsoft Azure.

The entry I voted for was TaxiCity, a really creative game that uses geographical data from Vancouver to overlay a 2-dimensional game world on top of the Bing maps for Vancouver where you, the cab driver, drive around the city picking up and dropping off fares. The execution was very well done, and the distributed team clearly worked very hard to put a lot of polish into their product — an A+ in my book.

The idea that won, however, was an application with a lot of potential called Find a Home. This is a real-estate-type tool that lists homes in the Edmonton area and ranks them by novel criteria such as family-friendliness (based on proximity to schools and parks) and safety (based on proximity to Fire and Police departments). It’s certainly a good use of open data and new technologies, but I felt it wasn’t quite “finished” yet, even by alpha standards.

All in all, Make Web not War was a great time.

The food was delicious and plentiful, the venue was gorgeous, and the staff were fantastic. I’ll definitely go back next year.

The rise of ubiquitous social networks has lead to a choice I often have to make: When I find something cool online, where do I share that content?

In the pre-MySpace days, when social networks weren’t really a “thing”, the decision was easy because there were only a small handful of choices: you instant messaged or emailed it to a few close friends, or if you were “that guy”, you forwarded it to everyone you knew. Fast-forward to today. If I find a cool link, I have all kinds of options:

• Tweet it.
• Share it in Google Reader.
• Share it on Facebook.
• Link to it on Yammer.
• Post it on LinkedIn.
• Send someone a private message through any of the above services.
• Blog about it.
• etc.

Which do I choose? If I only post the link in one place, I’m only reaching a subset of my total audience. But if I post the link in several places, I’m guaranteed to spam a few users multiple times. This dilemma is what I call the content-sharing problem.

My solution so far kind of sucks.

What I do right now is painstakingly case-by-case. If it’s particularly techie, it goes to one of the more techie networks: generally for something short and easy to digest, that’s Twitter, and for something longer, Google Reader. The idea here is that I want to match the content I’m sharing with other pieces in my friends’ feeds that are about the same length.

If it’s not techie at all, I’ll usually involve Facebook. Facebook is the venue that has the least overlap with any other network, and since I can post it on a specific friend’s wall, I can target that audience even more deftly. Since there’s unlikely to be much overlap, I’ll often share this again on Twitter or Google Reader, especially since they’re public and more persistent.

If it’s something work-oriented, that’s where LinkedIn and Yammer become more attractive. Unfortunately, these areas tend to have a huge divide in that many of my Twitter/Google Reader followers are also connections on LinkedIn/Yammer, and many are not. This is the most problematic situation, because I either don’t reach several people I care about or show a similar subset of people the same link twice.

I could go on, but you get the idea — it’s a mess. It’s case-by-case, and it’s probably NP-complete. It’s killing me.

Is there a better way?

So far, I can’t think of one. Even convincing everyone I know to follow me on one monolithic feed isn’t ideal, because with so many diverse people in one venue, my signal-to-noise would be different and probably pretty weak for each individual contact.

I’m grasping at straws here. Is there a technological solution to this that I could be using? Are there content-sharing etiquette rules that I should be aware of? Am I simply trying to be in too many places at once?

What do you do? I’m dying to know.

I’m a little late to the party on this one, but I have a few of thoughts I’ve been meaning to jot down since watching Microsoft’s MIX presentation about Internet Explorer 9. It’s a pretty in-depth video, and a touch long (~1 hour), but if you’re at all interested in browser technology it’s absolutely a must-watch.

Internet Explorer is no long playing catch up.

The resounding vibe I get from the video is that the Internet Explorer team is finally starting to get really serious about modern browser technologies. I’ve made my position on IE8 clear in the past — namely that it nailed CSS 2.1 but still wasn’t a competitive browser overall — and IE9 looks to be where that second clause will change. For the first time in about 10 years, Internet Explorer is innovating. For the skeptics out there, here’s a list of the features promised in IE9 that I’m excited about:

• Proper JS/DOM programmability.
• Standards-compliant HTML5 and CSS3 support.
• GPU usage for more complicated UI effects.
• Inline SVG support.

Now those first two aren’t exactly revolutionary, but it’s clear after the CSS 2.1 push in IE8 that the Internet Explorer team isn’t ignoring the standards anymore; they’re dedicated to promoting cross-browser mark-up, and they have the technical capacity to make it happen. This is great news for users and especially great news for developers, and hopefully it will push other browser-makers to fulfill their obligations to HTML5 and CSS3 as well.

What is new are those last two points. Using the GPU for rendering complicated UI effects such as the <video> tag is a welcome innovation to balance increasingly client-heavy rich internet applications. I can see this being a major reason for users to stick with IE9 (the first one in a while, in fact). And what is there to say about inline SVG other than finally? As long as the implementation isn’t falling apart at the seams I can see developers jumping all over this; I wouldn’t be surprised at all to see Firefox et al follow suit with similar support in the near future.

This is going to be huge.

IE9 is going to be the best version of Internet Explorer since IE4. It’s not going to be a standards-scoffing, security-lacking, feature-stealing deviant like its distant predecessors, and it’s not going to be that browser that we all hate rewriting our mark-up for. As a web developer who has lamented the existence of Internet Explorer for the majority of my career, I’m as surprised as I am pleased to say that for the first time in my life I’m looking forward to the next version of Internet Explorer.

I gave a talk today at work about Flex and BlazeDS, and in particular how to scale both to perform well during high-volume, real-time communication with a Java-based server (in the area of thousands of messages per second). Here are the most helpful bits from my presentation and the ensuing discussion:

Stick to StreamingAMF.

When it comes to real-time data transfer, StreamingAMF is really your only choice for a high-performance endpoint. It offers two simple advantages:

• Streaming connections allow for true push, rather than less-effective fast-polling.
• AMF is a binary protocol, so less data is transferred across the wire.

If you need a more thorough round-up of endpoints, I highly recommend DevGirl’s excellent endpoint explanation.

Batch messages going through BlazeDS to save bandwidth.

BlazeDS adds significant overhead to each message sent across the wire. With thousands of messages per second, this adds up to a very significant amount of bandwidth usage, to the point that performance will be adversely affected.

To compensate for this, buffer consecutive messages together and send several at once. Even a simple timeout that buffers message content for 10ms before sending it all as a single message will save an incredible amount of bandwidth, and a smart buffer that adjusts its timeout based on message activity will do even better.

This is easy to implement, and likely the biggest performance optimization available in a high-volume situation. Definitely worth doing if bandwidth and performance are a concern.

Override default BlazeDS connection settings.

BlazeDS sets two interesting connection limits too low:

First, the <max-streaming-clients> property is used to limit the number of clients that can simultaneously stream from the same server. BlazeDS limits this to 10 by default, so if 11 users connect to your application at the same time, that 11th one won’t get through. This is a serious fault, but we can raise the limit as long as we’re smart about how high we set it.

The reason there is a limit at all is that all connections in BlazeDS use blocking IO. This means that the maximum number of connections Blaze will support is limited by the maximum number of threads in the application container, since it will always require one thread per connection. Fortunately, modern containers support much more than 10 concurrent threads; Tomcat 6, for example, reserves 150 by default and even that can be boosted.

So the rule of thumb here is that you don’t want your connections in BlazeDS to outnumber the threads in your container, and that’s what you should base this limit on. If you require more than a few hundred concurrent connections, you’re out of luck and you’ll have to either wait until Blaze implements non-blocking IO connections, or upgrade to LiveCycle.

The second, much-less-serious configuration is the <max-streaming-connections-per-session> property, which is used to limit the number of concurrent streaming connections a specified browser can support. If this number is exceeded, new connections will not open on the same client. BlazeDS defaults this value to 1 for all browsers, so if a user opens two instances of your streaming app at the same time, on the same machine with the same browser, the second instance will not open.

This limit is dependent on the browser, and many do actually have a hard limit of one single streaming connection at a time. However, newer versions of Internet Explorer/Firefox/Safari, most versions of Opera, and all versions of Chrome support multiple concurrent streaming sessions. To take advantage of this, override the limit in your services config; I’d suggest looking at Patrick Heinzelmann’s awesome RemoteServices example to grab the specific browser numbers and a nifty code sample.

Get low-level with Flash Player.

There are probably a lot of neat Flash Player performance hacks that I’m not aware of, but here are two I’ve figured out so far:

The default frame rate in Flash Player is not very high. I’m not entirely clear on what it is; I’ve seen some sources say 24fps, some say 12fps, and some say it’s completely dynamic. Depending on what you’re doing, you may consider boosting it to draw more often. In particular, this can lower the worst-case latency between a message being triggered, processed and displayed. The flip-side here is that a high frame rate will raise your CPU usage, so that’s a trade-off to keep in mind.

Secondly, for the longest time I was updating the screen whenever I had new data to display. In retrospect, this was ridiculous. How do I know if I’m updating more often than the screen is being refreshed? How do I know how long it will be until this update is actually blitten* to the screen?

A much less naive approach is to make screen updates on the ENTER_FRAME event. This is dispatched right before Flash Player refreshes the display, so it ensures that whatever you do here will be instantly reflected on-screen. As long as this is the only place you’re doing screen updates, you know that you are doing exactly one update per screen refresh, which is ideal provided you’ve calibrated your refresh rate to match how often you receive updates.

The Profiler is your friend.

After all the above tricks have been exhausted, if you still need a performance boost, there’s always code-level optimization. Things like unrolling loops and minimizing allocation using the “new” keyword will add up eventually. A good way to find out which areas will benefit most from such refactoring is to use the profiler that comes with Flex Builder.

The profiler will allow you to view object allocation stacks and method performance. The former is a great way to find memory leaks and the latter is fantastic for finding out which methods are the slowest and thus most qualified for optimization. If you have any curiosity at all about this sort of thing (and you should!) I heartily encourage you to open up the profiler and fiddle around with it a bit; it takes a bit of ramp-up but once you have it figured out it’s a totally indispensable tool.

Hopefully this will be helpful to someone out there. Flex and BlazeDS are both very well documented by Adobe, but these were the handful of cases where I had to go well out of my way to find workable solutions.

* blitten: Past tense of blit.

Google Buzz is like a laser gun that turns bears into Skittles.

That’s what I tell people when they ask me about Google Buzz. Much to my surprise, even without any further explanation they’re often less confused than they were to begin with. That alone tells you something about Buzz (it’s purpose is murky at best) and something about me (I’m clearly great with similes). Once you get past that, though, there’s some truth to it (really!).

The basic idea is that you can think of specific instances where it would be really useful (such as: you’re about to get mauled by a bear), but in general it’s completely useless. You can go way out of your way to find a good use case for Buzz, much like you can drive out to a forest inhabited by bears and spend all afternoon tracking one down, but that’s not how I like to spend my afternoons or my time online.

The problem I see with Buzz right now, is that it’s not as powerful as Google Reader, Twitter, or any other social tool, and it doesn’t offer any compelling features to help early adopters attract the masses. I’d simply rather read status updates and find neat links through other web venues. That’s not to say that Google got everything wrong here, and it’s not to say it has no potential — there’s just not a whole lot to like about Buzz right now.

What I would do with Buzz.

I think Buzz should aggregate everything from all my existing web communities, and let me filter it per-person.

If I’m wondering what my friend davefp is up to today, I should be able to pop into Buzz and instantly see any content of his that I can access in any of our mutual online spaces. His Twitter, Tumblr, Google Reader, blog; anything he’s got going on that I could check in each of those tools individually, right in one place. That’s when I would start Buzzing like a bee (again with the similes — sorry).

Obviously, it’s not easy to set up that sort of scenario, and you could argue that this is what Buzz is trying to do and that it’s just a few (light)years away — but the APIs exist for this! It’s just a matter of stitching them together in a way that’s coherent and seamless, and doesn’t take very long to set up, even if I have a lot of contacts on a lot of networks.

So that’s my take on Buzz. Now if you’ll excuse me, I have 8 different networks to dip in to, and some Skittles to snack on…

Aside: have you seen skittles.com lately? You should check it out — we need more designs like this.

Context is a very important factor in software development. Knowing the conditions under which your software will be used is an integral part of crafting a positive experience for your users. Many companies take this to heart and create truly engaging software that really connects with its users, but the vast majority miss the mark. While I’m sure I’d have no trouble pointing out a myriad of context-related issues in software made by Average Joe Developer, today’s focus will be on showing that even the top names in software aren’t perfect.

Exhibit A: The iPhone’s Clock.app

Let me tell you a story. A few weeks ago, the fiancée and I were scheduled to meet with a potential wedding venue early Saturday morning. Given that it was a bit out of the way and we tend to oversleep, we thought we’d be smart and set an alarm using the iPhone’s default clock app.

So Friday night, we set an alarm thinking it would wake us up Saturday morning. It did not; it turns out the alarm we set was for weekdays only! While this was entirely our fault, I’m still going to call Apple out on not taking context fully into account: when we set the alarm, why didn’t the app warn us that the alarm wouldn’t go off the next morning? I would imagine it’s very rare that anyone sets an alarm more than a day in advance. It’s much more likely that when someone sets an alarm at night, they expect it to wake them up the next day. This is a case where a neat feature is actually an annoyance because context isn’t handled as well as it could be.

Exhibit B: Google Maps

Continuing our story, while I was frantically trying to get ready I was loading Google Maps to get directions to our appointment. After punching in the address and asking it to route us there, Google Maps told me the trip would take over 9 hours. I freaked out! We don’t have 9 hours, we have 30 minutes; is this the right address? Did we accidentally book an appointment at a venue 9 hours out of Ottawa?

Actually, it turns out I had Google Maps set to give walking directions. Again, my fault, but again, where were the developers on this one? Did they really think I wanted to walk over 9 hours to get somewhere? Why not recognize that I was probably looking for driving directions and put a message at the top of the screen asking if that’s what I meant?

(For the curious, this story did have a happy ending: we made it there a slight 15 minutes late, and this was the venue we eventually chose for our wedding.)

Exhibit C: Firefox’s Spell-Check

Firefox is an incredible piece of software. It is currently the browser of choice for about one quarter of all internet users, and in many ways helped to revolutionize the web browser market. But one area where it hasn’t really advanced as far as it could have is its built-in spell checker. I don’t have a fancy story for this one; the data speaks for itself. Here is a list of words that show up as spelling errors in Firefox 3.6:

Some of the internet’s most popular websites:

• YouTube
• Facebook
• Myspace
• Flickr

Well-known web technologies:

• Skype
• Silverlight
• Webkit
• WordPress, CMS
• PHP, CSS (it gets HTML)

Very common computer words:

• Inbox
• USB

Extremely successful desktop software:

• Photoshop
• PowerPoint

Apple products:

• iPod, iPhone, iPad
• Macbook
• iMac
• OSX (it gets Linux and UNIX)

These are all very common words in internet parlance, and it’s ridiculous that they are highlighted as possible spelling errors. Why not add them to the dictionary? A simple white-list that could be crowd-sourced to the community seems right up Firefox’s alley; I wouldn’t be at all surprised to see this addressed in a future release.

What can we learn from this?

My main take-away here is that context is a big factor in software development, and one of the hardest to get right. Even the big guns have room for improvement, which means the rest of us likely do as well.

Adobe Flash is at an interesting point in its existence. For about a decade, it was the only way to get rich, dynamic content onto the web. If it was the year 2001 and you wanted a really sleek UI, or video, or any kind of animation, Flash was your best bet — it was pretty much a monopoly. Then things started to change:

• DHTML started to take over some of the really basic use-cases for dynamic events like rollovers and showing/hiding content.
• AJAX made truly dynamic content easier for the non-flash world.
• The mobile web started to take off, with most devices not capable of supporting Flash.
• Microsoft released Silverlight, a competitor to Flash in the rich interface space.
• Apple started releasing wildly popular devices that intentionally avoided supporting Flash.
• Browsers started implementing support for HTML5 and CSS3, which are slowly being adopted by designs that would historically require Flash.

Slowly but surely, alternatives to Flash have been picking up speed, and things beyond Adobe’s control have prevented Flash from penetrating certain markets (mobile in particular). What does this mean for Flash as a technology?

Flash isn’t going away anytime soon…

This isn’t one of those posts about how HTML5 or the iPad or global warming is going to spell the end of Flash. Flash is a major player in many areas of the web, most of which won’t change anytime soon. In particular:

Games — There are tons of online Flash games. This is a huge market that Flash has absolutely dominated since day one, and none of the technologies mentioned above can compete with Flash on this level of interactivity.

Video — Like it or not, HTML5 is not yet strong enough to handle cross-browser, web-based video. Even when it is (and it will be sooner than you think) Flash will still be used well into the future because it’s the only solution for legacy browsers, and the vast majority of users don’t update their browsers as often as they should.

On top of that, Adobe has created an entire ecosystem of software and a vibrant community for designing, building, and publishing Flash-based applications. Plenty of people are heavily invested in these tools, and no amount of evangalism is going to convince them that their problems could be better solved by today’s Flash-alternative du jour.

…but Flash will start having a reduced role on the web in general.

It would be unrealistic to pretend that these new technologies aren’t eating into Flash’s market share. For one, even in the most complex cases, some projects are choosing Silverlight over Flash. Not the majority (not even close) but more than none, and Microsoft is a powerful competitor that can compete with Adobe on the development tools and community levels.

Secondly, HTML5 and CSS3 can do some pretty neat things. For cases such as modern, dynamic navigation and simple logo animation, it will soon make much more sense to use features supported by the browser than a heavyweight proprietary plug-in; especially if all you need is a quick piece of eye candy.

Finally, there are the problems caused by Apple. I can think of three:

No iPad/iPhone Support — The longer this keeps up (and I don’t see it changing anytime soon), the more likely it is that someone will create a cool, interesting way to do fancy, Flash-like things in an iFriendly format. And then a general-mobile format. And then a web format. The last thing Flash needs right now is for some brilliant start-up to shake things up even further.

Macbooks are getting popular — Adobe claims that Flash runs on every platform ever, but as Chris Rawson astutely points out in this excellent article, that’s been easy to say while most of the world has been running Windows. With Apple’s laptops gaining popularity, people are starting to realize that Flash doesn’t run as well in OSX. The more Macbooks Apple sells, the more Adobe’s claims of market domination will start to dissolve.

No iPad/iPhone Support: take two — I want this website to be viewable on the iPhone, the iPad, and whatever whimsical hardware Apple comes up with next. That alone means I’m not going to use Flash in my blog’s design, ever. I’m admittedly in a minority here, but I wouldn’t be surprised if today’s kids getting into web design are also going to want to show off their cool, new, standards-compliant sites on their cool, new, iApproved devices. This sort of trend will slowly but surely push Flash out of the cool-new-site space.

Getting along with OSX is something that Adobe is going to have to work towards to keep Flash competitive, especially as new markets evolve out Apple’s hardware.

I’m not anti-Flash.

I’ve been using Flex Builder to build cutting-edge Flash applications for years, and I still believe there are many cases where Flash is a legitimate choice for creating a rich internet experience; there just aren’t as many as there used to be, and this combination of new, exciting technologies and pressure from Apple are making for some exciting times in the world of web design.

2010 is shaping up to be a wild ride for Flash and its competitors, and I can’t wait to see where it takes us. What are your predictions?

Up until very recently, I was seriously considering getting a Macbook. I have a desktop PC that covers my day-to-day tasks, but I want something I can use from my couch, and in particular I’ve started to really miss OSX (I used an iBook as my primary machine up until more recently than I’m willing to admit).

Then Apple releases the iPad, which promises to do everything I was planning to use my Macbook for at nearly 1/3 the price. Now what? Do I keep eying the Macbook or start counting the days until the iPad hits stores? I’m completely torn.

First let’s get a few things out of the way. I don’t want the 3G version of the iPad. I have enough monthly bills already, and my iPhone covers all my 3G needs. I’m also not the kind of person that needs much space, so the low-end iPad suits me just fine. And I don’t want a Macbook Pro; a regular Macbook is easily enough power for me, though I would probably take the ram upgrade for an extra $100. With that in mind, we’re looking at $500 for the iPad vs $1200 for the Macbook.

I want something I can use while sitting on my couch, and all it has to support is writing blog posts and your standard email/browsing activities. Both machines are perfectly capable of performing these tasks, and I’m already fluent in both OSX variants from owning an iBook and an iPhone.

Now for the interesting part: the advantages each device offers.

Advantages of the iPad:

• It’s significantly less expensive, as we’ve already discussed.
• You can turn it sideways. That may sound ridiculous, but I much prefer web browsing on a screen with more height than width.
• I love the form factor. Watching the video on Apple’s website… It doesn’t look like he’s holding a tablet and running a browser; it looks like he’s holding a browser. This level of UX is absolutely a step above anything else on the market, Macbook included.
• It has substantially more novelty, and all kinds of potential that we don’t know about yet.

Advantages of the Macbook:

• It’s a well-established line. You know exactly what you’re getting, and how awesome it is.
• Multitasking. I’d like to be able to have a browser open at the same time as Twitter and an IM client.
• The platform is more open. I like using browsers other than Safari, running commands in Terminal, and hacking together useful AppleScripts.
• What if I want to do some iPhone development? I’d need a Macbook, unless Apple releases some sort of iPhone-specific XCode for iPad (and who’s to say they won’t?)

It’s a mess. There are so many differences, but the advantages of each individual device are so appealing that I can’t make up my mind. Worst of all, I’ll probably regret either decision — if I go with the Macbook, I’ll sigh longingly every time I see an iPad; if I go with the iPad, I’ll curse every time it can’t do something that the Macbook can. I’m still undecided, and that’s not likely to change anytime soon.

What’s your take?

Should I go with the iPad or the Macbook? Are you in a similar position?

Yes, another post about being engaged (it’s kind of this week’s theme). I promise this will be the last one, at least for a while; there are just a lot of interesting thoughts coming out of planning a wedding. We’ll resume our regular totally-non-marital posts at one per week on Monday.

I’ve been meaning to write up a good post regarding my take on Google Wave pretty much since I launched this blog in October ’09. The trouble was, I could never find a really good use-case that demonstrated how powerful and useful Wave is — until now. So without further ado:

I don’t understand how people planned weddings before there was Google Wave.

My fiancée and I are both the type to do a lot of research and planning before a big financial decision. So when it came to booking a venue, with so many different options and associated costs, we both dove right in. The only problem was that we had a really hard time staying in sync; we would both research the same venue or lose track of contact information for a place we really liked — it was a disaster. We tried ad-hoc discussions in person (this didn’t work; human memory is far too fallible) and a mess of emails (I had to scrub my inbox with a sponge after that one) but we found we were still stepping on each others’ toes. Then it dawned on me:

What we really needed was a wiki.

We needed someplace where we could both see and add and edit information, highlight important dates or phone numbers, and easily compare venues to one another. Nothing huge (a CRM would have been way overkill), just a light-weight wiki that would be approachable for my not-very-geeky soulmate.

So I fired up Google Wave and spent a couple of minutes explaining it to her. Now we have a wave for wedding venues, where each wavelet (that’s what the posts in a wave are called) is about one venue. When either of us comes across a cool-looking venue, we can quickly scan the wave to see if it’s already there, and if it isn’t we can add it and fill in some quick details. If we want to contact them, we highlight the contact info, and if we make an appointment to visit a venue, we highlight the date as well; this way even at a quick glance we can quickly see when our appointments are and if there are any left to make. If either of us have comments about a venue, we can reply to its wavelet; this takes care of the usual meta-discussion in an informal but persisted way (the indent makes it easy to ignore when skimming).

So far, this is working incredibly well. We’re both completely in sync all the time, and it’s easy to find key information by quickly looking in one place. We’re already starting to add new waves for other things we’ll both want input on, like the photographer, the DJ and the cake. I have no idea how else we could be doing this as efficiently as we are; Wave is suddenly crucial to our planning process.

What went right?

I’d like to touch briefly on why this has worked out so much better than my previous experiences with Wave. I think one of the big problems with Wave is that information tends to get scattered — it’s easy to lose something in a mountain of replies, and the inability to hide or mass-delete old content causes a lot of unnecessary and frustrating sifting. What I did differently this time was enforce some basic rules about how the wave should be structured: one venue per wavelet, replies are allowed for discussion if required. This way there’s no checking to see if that golf course with the gorgeous gazebo is nested somewhere in a chain of replies, or deciding what depth to add that maple farm that four different people have recommended. They’re both easy decisions, and sticking to these informal rules really pays off in terms of keeping the wave easy to read and update.

Have you found a good use for Wave?

I’m curious to know what other creative uses people have found for Wave. If you’ve got something good, please share!

This week’s entry is a double feature about Internet Explorer. Part 1 examined why IE4 was awesome. Read on for part 2, where I’ll admit that I’m grateful for IE8.

Let me start by saying that in general, I find Internet Explorer appalling. The fact that so many people have been supporting an insecure, slow, feature-weak, standards-deviant browser with serious rendering problems and an awful user interface for so many years afflicts my soul with such utter disdain for Microsoft’s line of browsers that I automatically regard every new incantation thereof as an affront to both the web and mankind as a species.

Now that that’s out of my system, I don’t entirely hate Internet Explorer 8. I wouldn’t use it, not with so many better alternatives just waiting to be explored*, but it does offer one massive improvement over its predecessors that I’m very pleased with: IE8 has fantastic CSS 2.1 support.

I’m not making this up.

Check out the standards support table on this page, specifically the secion about CSS 2.1. Look at the massive difference between IE6/IE7 and IE8. Even Firefox 3 and Opera 10 can’t claim the same level of compliance. IE8 isn’t just a competitor when it comes to supporting CSS 2.1, it’s a role model.

This is a big deal.

For the first time ever, web developers can finally count on using standardized CSS to create a modern web experience without having to worry about “how to handle Internet Explorer”. Granted there is still the matter of older versions of IE, but with Windows 7 repairing a lot of the damage done by Vista, more and more users are upgrading to a new OS, and with that, a new browser. Writing cross-browser CSS is becoming easier than ever before.

Of course, many people will argue that simply supporting CSS 2.1 isn’t good enough (and they’re right). Internet Explorer is still way behind its competitors when it comes to newer standards such as HTML 5 and CSS 3. But what if this is just the beginning? Internet Explorer 9 is already well into development, and if Microsoft can turn the hobbled CSS implementations found in IE6 and IE7 into what is now in IE8, who’s to say they won’t be able to step up support for CSS 3 and/or HTML 5 in IE9? In as little as a year or two from now, Internet Explorer may be a legitimate browser for cutting-edge web experiences.

Share some thoughts!

What do you think of IE8? What about Internet Explorer in general?

* For the curious, the browsers linked in that phrase are the ones that were selected to show up in Windows 7′s “browser ballot” in Europe due to antitrust charges brought by the EU against Microsoft’s bundling of Internet Explorer with Windows. Computer World offers a great summary and FAQ on the matter.