I was going to post a comment in response to Scoble's
blog entry shown below regarding browser support, etc, on Live.com. I decided to post it here as I felt it was worth reiterating what I stated back in September.
From Scoble's blog:
By the way, remember last week when I said Microsoft doesn’t care about influentials because we don’t support Firefox and didn’t get it working in Live.com? Well, last night I had sushi with Sanaz Ahari (and Chris Pirillo and Ponzi Indharasophang). You might not know Sanaz, but she’s one of the key team members that’s building live.com.
She apologized for not getting Firefox support done. She told me she, and her team, had been working 18 hour days to meet last Tuesday’s deadline and she got sick the week before launch so simply didn’t get it done. She says, on her blog, it’ll be “very very soon.”
It’s another reminder to me that software isn’t written by machines, it’s written by people, and when deadlines hit sometimes you can’t get it all done and have to prioritize what’s most important to get done.
She also says that Live.com has a lot more to come and that it shouldn’t be judged on its first day in business. It’s now my home page, so I’ll report when new goodies show up.
There are lots of passionate replies to Scoble's entry. I don't have anything additional to add beyond the above statement on Firefox support - there was a schedule, priorities, etc and some were and were not met for the first release. We should all remember every company has business requirements, priorities, and ultimately a schedule to follow - whether we agree or disagree. (I seem to recall that Google's GMail and Reader did not support all browsers either when they initially released).
Now, reading the comments on Scoble's site, I actually was very pleased - the comments challenge us to do better. I prefer passionate comments (both positive and negative) over indifference.
On the browser support issue, I have already explained our issues regarding
Opera, Safari, and potentially any other browser that may come along. It is a widespread misconception that simply supporting xhtml and css magically enables full-blown cross-browser support. Regardless of which browser is right or wrong, there are differences between browsers in rendering and DOM support and there is a significant cost testing and fixing code and presentation across all possible permutations.
Reiterating my points made in my earlier
blog entry (I recommend reading it), for Safari and Opera specifically, we are leveraging features in the DOM/ JavaScript that are not supported (as far as we can tell) by those browsers .
On the technical front, as I have been saying for months, we are pushing the envelope by building every one of our properties on a shared client application framework. This offers us very unique opportunities around our ability to develop and "remix" experiences. For example, what other company has opened up their development methodology letting anyone extend the experience with their own custom components (
Microsoft Gadgets)? To enable Gadgets (which match our internal development patterns), I had to push the limits of the DOM, create new development patterns, and design a system that up to this point has not existed. To put it succinctly, this is not your father's DHTML and goes well beyond the simplistic "AJAX" patterns everyone gets so hyped up about.
You may also be surprised to hear we have a goal of writing no browser-specific code in any of our UI or business logic. Again this is possible by having a single, shared methodology (with the exception of targeted CSS overrides as necessary to cover rendering differences). I am sure those who have built Gadgets and examined the code have noticed it is rare we isolate one browser over another. We accomplish this by equalizing the object models, hiding browser-specific bugs, etc., from all our development. This yields great efficiencies. Developers (including third-party Gadget authors) can focus on the task as much as possible and not the browser. We have proven this model with how we enable Firefox support at an API level (rendering issues again are separate). Unfortunately, this approach also implies browsers have specific capaibilities which are outside of our control.
The browser-related technical issues are applicable to all our Live.com properties. I am available to sit down with browser vendors to discuss these or any other issues. (I know people who work on Firefox and we correspond with each other as it is mutually beneficial).
工具 
帮助
