Scott's "SiteExperts" Place

Talking about Gadget devs, come out and play!

Wed, 02 Aug 2006 06:48:18 GMT

I know it has been awhile since I posted. Tonight we have big news! MSN Spaces is now Windows Live Spaces. The Windows Live vision is taking shape! In addition to tons of cool improvements (themes, social networking, and more), now Gadgets can be built for Spaces as well as Live.com. Stay on top of developing for Spaces at the Spaces Platform blog.

One of the best aspects of Gadgets on Spaces is their viral nature. See a cool gadget on someones space - just click on the + sign and you can quickly add it to your Space. Let the fun begin!

Quote

Gadget devs, come out and play!

Admit it.

You've always thought MSN Spaces was pretty cool -- that we did some things right and would work hard to smooth out any rough edges over time. But, you weren't sure if the Spaces team would ever let developers outside the company party in someone else's space. Well, a big part of joining the Windows Live family today is support for web gadgets written by anyone including YOU! Thanks to the great work done on Gadgets to date, you can now write a gadget that works both in Live.com (personalized portal) and Spaces (online expression/identity). And, it only takes one person adding it to their space for your gadget to become popular -- visitors to that space can choose "Add to your space" or "Add to Live.com" right from the header of the gadget, then visitors to that space can add to their spaces, and it's off to the races!

What kind of gadget makes sense in a space?

Remember that the Live.com portal is about YOU catching up on the world.   Spaces is about the world (however big or small you define it with the permissions you set) catching up on YOU. Users will decide which gadgets are worthy of adding to their space or not, and given our experience with Spaces features to date, the ones that will be the most successfull will be:

Customizable -- let the space author personalize the gadget so their instance of it is different than another Spaces user's instance. This could be as simple as letting the space author select the city they want to show weather for OR as complicated as pulling the user's account data in from another service (ie, his/her Netflix queue).

Reflective of the author's personality -- a gadget that helps the author to be creative with little or no work is more relevant than one that lets a visitor come to a space and check their mail account or convert their currency. All of those gadgets are killer apps; it's just the ones that are more like sharing your photos or music tastes will probably be more popular.

Adaptive to our rich themes/layouts -- after adding your gadget to your own space for testing, try selecting a bunch of dark and light themes AND moving the gadget between our narrowest and widest columns to make sure it works well in all scenarios. You want that puppy to shine!

How do I get started?

1. Build a Windows Live web gadget according to the SDK available at the Windows Live Dev site.

2. If your gadget has any settings/edit UI that visitors shouldn't see, then use the following code to detect whether Spaces is running the gadget in author mode and show/hide the UI accordingly. There is a p_args argument outlined in the gadgets SDK and we've added a new method off of that called getMode(). You can do a simple comparison of the value returned from that method call to determine author vs. visitor mode.

Something like the following:



         foo = function(p_elSource, p_args, p_namespace)

         p_args.module.getMode() == Web.Gadget.Mode.author

3. Add the gadget to your own space using the following Spaces API:

http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=URLEncodedPathToYourH ostedGadgetManifestURL

Switch between "Edit your space" and "View your space" to see how it behaves in both author and visitor modes. If your manifest file, Javascript, and CSS are hosted anywhere but Windows Live Gallery (gallery.live.com), the gadget can only be added for editing/viewing by the space owner. It will be hidden to visitors.

4. Zip up your manifest file and supporting Javascript/CSS files and submit that gadget package to the Windows Live Gallery so other visitors can add it to their space by going to Customize --> Modules --> "Add gadgets from Windows Live Gallery". Once it has been verified to work in each service, it will appear in the Gallery for users to add to Live.com or Spaces. Make sure you use relative URLs (mygadget.css instead of http://foogadgetdeveloper.com/mygadget.css) in your manifest XML to point to the scripts/CSS or the gadget will be rejected during verification.

5. If you upload a cool gadget to Gallery that you think will be a hit with Spaces users, comment on this post or send mail to spgadget@microsoft.com.   Same thing applies if you have feedback or feature requests for making gadget development for Spaces better.

We'll be updating the Gadgets SDK and sample code on dev.live.com very soon to reflect the additional Spaces items. In the meantime, you have everything you need above.

Good luck stormin' the castle!

-- Jay Fluegel

Watch my Engineering Great AJAX Experiences Talk...

Thu, 04 May 2006 10:59:08 GMT

My presentation from the Mix06 Conference, Lessons from the Trenches: Engineering Great AJAX Experiences is now online:

NGW020 - Lessons from the Trenches: Engineering Great AJAX Experiences

Description:
Explore the challenges and lessons learned developing the Windows Live and Gadgets Web client frameworks powering Windows Live, Hotmail (Kahuna beta), Spaces, and more. This technical talk presents design and architectural considerations for building interactive AJAX-like sites. See how componentization, network management, accessibility, page composition, and more impact the design and engineering of your Web application.

(To find other talks, go to the main Mix06 Sessions Page).

Gadgets and Cross-Browser Development

Thu, 27 Apr 2006 06:35:01 GMT

We are working hard to improve the Gadget framework documentation. In the meantime (and as we improve documentation), I am working on a series of short tutorials, tips, and highlights introducing how to use the Gadget framework and the underlying APIs.

I am going to start with our compatibility layer. After exploring various third-party gadgets being developed for Live.com, I discovered that many developers are still struggling with the API differences between Firefox and Internet Explorer. Most common, I see various tricks to handle the event model differences where IE uses a global event object and Firefox passes the event object as an argument to your handler.

This is not necessary when you build Gadgets. Instead, you should be leveraging the underlying compatibility layer that is part of the overall Gadget framework.

As I posted last September, as we develop our properties, almost none of our application logic contains browser specific code. Instead, we develop once to the Internet Explorer API and our code runs without modification in Firefox. This occurs because we download a special script that emulates the most useful IE’isms inside of Firefox and in a few cases, Firefox/W3C’isms in Internet Explorer. In this article I highlight the most useful methods and properties of this layer (I promise we will develop a full reference in the near future).

Event Model

This is easy – always attach events using attachEvent and detachEvent. Do not assign event handlers using function references (e.g., myElement.onclick = doThis) nor use the addEventListener approach.

In your event handlers, don’t worry – you will always get the global event object. For example:

function doClick()
{
  alert("You clicked on a " + event.srcElement.tagName + 
     " element");
}
document.body.attachEvent(“onclick”,doClick);

Also, as a general practice (I will cover this more in later articles but this is extremely important), when writing Gadgets, be sure to detach any event handlers in your dispose handler. Otherwise, your Gadget will leak memory due to known browser issues.

What can you do with this event object? You can check out the MSDN reference as most properties are exposed. In addition to the standard properties, below are the list of properties we added to Firefox:

srcElement
cancelBubble
offsetX
offsetY
x
y
returnValue
button (few issues as Firefox does not properly distinguish between the left button and no button)
fromElement
toElement

We have also gone further and extended Firefox with the very useful mouseenter and mouseleave events. As long as you attach these events using the attachEvent and detachEvent methods, these events fire just as they do in Internet Explorer. These events are very useful for quickly and easily detecting when a mouse enters or leaves a specific element. Again, check out the MSDN reference for more details.

We even have a reasonable emulation of mouse capturing. However, this is most useful in the context of an entire web-page not within a simple gadget. This is because mouse capturing in Firefox only fires within the context of the browser client area. Regardless, when using mouse capturing (setCapture and releaseCapture methods), the mouse events fire properly on the correct elements.

We also fixed the Firefox onclick event to only fire for the left mouse button (Firefox fired for all mouse buttons). This little difference could cause you grief in your application. (For those of you who noticed that we also accidentally prevented the ability to open pages in new tabs via the middle button, that will be fixed real soon).

Useful Element Methods

Internet Explorer also supports a number of very helpful methods and properties on every element. These APIs simplify day-to-day programming and are very useful for building your application. Below are the list of element functions we added to Firefox. Again, check out MSDN for the details (linked for each item below) on how they work.

The currentStyle property returns the value actually being applied to the element. We currently support a subset of CSS attributes that we have found useful: border, margin, padding for Top, Left, Right, and Bottom; position; height; width; zIndex; color; and direction. We will most likely extend this list over time.

Useful style properties

We also extended the properties available on the style object with the extremely useful pixel* properties. These allow you to easily manipulate the dimensions of the element (assuming you are working with pixels). We also added the cssText property which gives you a serialized representation inline style.

XPath Expressions

When dealing with XML documents the ability to query for specific nodes is especially useful. Trying to decipher the difference between IE and Firefox for querying XML can be extremely painful. So, we provided support for two very straighforward IE methods, selectSingleNode and selectNodes.

Creating xmlHttp Objects

When you need to create a new XML Http Object, you can now simply use the standard approach, var y = new xmlHttpRequest(). However, as I will cover in future articles, I highly recommend you leverage our built-in network stack for all your network requests.

Parsing XML

Last, but not least, you have a string that you want to load into an XML DOM - just use the standard DOM Parser object:

var dp = new DOMParser(); 
var xmlDom = dp.parseFromString(yourXMLString);

This concludes my very brief and fast introduction to our compatibility layer. We are continually expanding the functionality. For example, we have basic IE filter support (alpha filters assigned via script will also apply in Firefox). I will cover these in later posts. For now, resist the urge in your Gadgets to author code differently for each browser. Instead, take the easy road and let our compatibility layer do all your heavy lifting.

Last, since it will inevitably come up, see the following post on why we support or don't support other browsers (while the post talks about start.com it is relevant to all properties on our framework).

What we learned building Live.com (or why are we slow)?

Tue, 25 Apr 2006 23:29:32 GMT

Over the last 18 months, we have explored how to build a highly-interactive, customizable, and extensible portal. The first iteration was a simple portal on Start.com. We created various iterations (start.com/1, start.com/2, start.com/3) which have evolved into the first fully extensible portal on Live.com. Today, from Live.com to the Kahuna (Hotmail) beta to MSN Spaces, and so-on, we are investing heavily in building very rich, interactive experiences. With these investments, we are learning a great deal on the right and wrong ways to engineer rich, interactive web-sites.

Underneath all our Windows Live properties, we share a common framework for how we engineer our client experiences. The framework is very client-centric where we composite most of the page client-side. For example, if you were to view Live.com’s HTML, you will notice that it serves a web-page “shell” and meta-data that describes the content. This meta-data is interpreted by the Live.com application and then rendered. This approach is extraordinarily flexible as we can quickly enhance and extend the application without any heavy server lifting. However, as we have learned and is being evidenced by our customers, without care, performance degradation can quickly outweigh all other benefits.

As you examine Live.com, and for the technically savvy, explore the underlying browser technology, it is easy to question whether we as Microsoft and the industry as a whole are pushing the browser too far. The current crop of rich applications while cool and interactive are starting to fare poorly performance-wise against their traditional brethren. So much so that an often posed question is, where do we go from here? And is it time to reexamine building rich applications?

First, let’s step back and very briefly look at the web versus traditional software. With traditional software, you would go through various design phases starting from specifications, to architecture documentation, to development, to usability testing, to testing, and eventually to ship. The entire approach had a fairly long lead time (up to years). Once released, updating the software was difficult and many times very cost prohibitive. This created a very high-bar. The web has removed almost all those barriers. On the web, we can now experiment and develop software with near real-time feedback and very fast release cycles.

I view the Web 2.0 phenomena as being very early in the development lifecycle. I am not prepared to dismiss any approach, pattern, or methodology as we are still in the learning phases. In the case of Windows Live, as we push the browser, we are also learning a great deal. Examining performance specifically - when I look at Live.com today, I see incredible innovation. We are pushing the limits of extensibility (gadgets), reuse (shared frameworks across all our properties), and are taking chances to drive new user-experience standards (look at how we present search results). On the contrary, I also see an application whose performance is starting to become painful to use. The page currently takes a long time to load, especially on the first visit. Beyond our user’s feedback (we do read all messages), broader industry pundits are quick to throw in the towel on the entire technology.

We are taking a different approach to this problem. We are challenging ourselves to prove that we can architect a performance driven, rich extensible experience. We are leveraging our gained knowledge shipping the many iterations of Start.com and all the beta products we are developing to improve our shared architecture and drive best patterns. Using the current Live.com as a simple case study, below I illustrate a few of the performance-oriented technical issues that we are working on quickly addressing:

Manage your Connections Carefully

If you were to examine Live.com at the network level, a reasonable person would quickly conclude that we are making too many connections. We decomposed this issue as follows: First, we are hitting an IE 6 issue that causes un-cached images applied dynamically via script to download on each reference. This issue typically manifests itself on slower connections – the time when bandwidth is most at a premium. We are baking a solution to this problem directly into our frameworks so that we pre-cache dynamically applied images before reuse. Next, every RSS feed and Gadget manifest is a unique request. This creates a web-page that is very “chatty” – an AJAX characteristic that you should work to avoid. We will solve this by intelligently batching multiple requests into a single request (and are exploring even more efficient means for the longer-term)

Parsing XML is Slow

We have also learned that merely parsing the RSS XML can be expensive in the browser. When we parse RSS, we are merely translating it into Javascript structures to be further manipulated. Since our server’s are already normalizing feeds to a standard format, instead of serving the RSS feed directly, we are going to translate the feed directly to JSON (Javascript structures). As a simple benchmark, on my fast developer machine we went from 400ms to parse 150K of RSS to 15ms to “execute” the JSON response.

Caching and Connection Management is Essential

Network bandwidth and connections are a scarce resource. Managing them is essential to providing fast experiences (especially for subsequent loads). We are evaluating the optimal approaches for splitting resources across multiple servers to leverage as many simultaneous connections at once (the browser is limited to 2 active connections per domain). We are also reviewing all resources to make sure they are set with appropriate expirations. In general, almost all content should have expiration, even a very short one (e.g., if the user leaves the page and hits the back button, the page should be re-rendered entirely from the cache).

Staging the Application

One of the biggest challenges with a very rich web-application is deploying the code. The richer the site, the more code that is needed. In the case of Live.com today, the entire application deploys before anything renders. However, our underlying framework supports dynamic and prioritized deployment – we just were not properly leveraging it. We are now focusing leveraging this pattern so that we can “stage” the application. We will be able to deploy the minimal code necessary to retrieve content and render the page and subsequently download features in priority order (e.g., render, then get drag-drop code, then get the RSS image rotator code, etc). For features not yet in use or visible, we can deploy those last or even on demand. Staging an application is fundamental to maintaining high-degrees of perceived performance.

Server versus Client Rendering

Traditional web-pages are generated via the server. Live.com and many of our properties are very client-centric where the client constructs the web-page from the user’s meta-data. In general, the first time a web-page loads, a server-generated page will almost always be faster. However, with a properly architected web application, we are discovering that our subsequent loads on a client-side generated page (especially when we stage the application) can be much faster than a server-oriented page. This occurs because our client-oriented approach is highly cacheable and loads asynchronously, even off the cache. The only content we need to download is the user’s meta-data. The rest of the page, scripts, and behaviors are cached indefinitely.

This summarizes a few of the performance-driven challenges we are addressing. Internally, we have developed a complete prototype that validates we can build a high-performance, scalable version of Live.com that load and run near-instantly to within seconds (on broadband). We are working on integrating these improvements into the shipping site as quickly as possible. Over the coming weeks and months, expect to see continuous noticeable improvements.

Update: Beyond performance, the Live.com team just posted the goals for the Live.com page.

This deserves a link...

Mon, 10 Apr 2006 01:31:43 GMT

I've been called lots of things, but this is the first time I believe I was called a treasure... Thanks Scoble :-)

Talking about "Hack Day" is creative play at work

Mon, 10 Apr 2006 01:28:28 GMT

In Saturday's Seattle Times, there was a short article about Microsoft's Hack Day. I was part of the virtual team that helped kick off and organize the first two hack day events. They serve as a great venue to experiment and meet others. The first two focused on hacking Spaces modules and building unique gadgets. We typically give a few short presentations, and then let everyone loose on the code base to experiment and innovate. Check this article out to get a little glimpse into the Windows Live culture...

Quote

"Hack Day" is creative play at work
...
And that's how a group of 75 Microsoft developers set out Thursday to brainstorm at an internal event called "Hack Day."
...

Talking about: Ric Merrifield on the Motion Initiative

Tue, 04 Apr 2006 21:31:40 GMT

Prior to rejoining MSN/ Windows Live, I spent a few years trying something completely different. I was an architect on an incubation project (Virtual Enterprise Team) exploring and bringing together SOA with how businesses work. Ric continues driving this work. I guarantee you will learn something new and different in this Channel 9 video.

Ric Merrifield - Microsoft gets down to business with Motion initiative

"Ric, director of strategy on the top secret Motion Incubation team, runs the Motion initiative. What's that? It's a group at Microsoft that studies how businesses work and looks for opportunities to help them do their business better. They made an entire map of how business works.

Motion's research led to the acquisition of Great Plains, too (which led to the Dynamics suite of services/applications).

Enjoy this look into a team you've never heard of before today and see how Microsoft approaches new markets and new acquisitions, and how it learns from other businesses."

Presentation: Lessons from the Trenches

Tue, 21 Mar 2006 22:22:22 GMT

I just gave my Lessons From the Trenches talk at the Mix06 conference. As requested, I uploaded my slide deck and you can find it at http://www.weblogging.com/decks/lessons.ppt. I believe the talk was also videotaped as a webcast and will hopefully be able to make that available.

UPDATE: If you attended the talk, be sure to provide feedback at http://content.mix06.com. Also, I expect a webcast of the talk to be available within 3-4 weeks.

The Live.com team has outdone themselves...

Wed, 08 Mar 2006 08:10:12 GMT

Go check out http://www.live.com.

I expect to see more posts from the team after they get back from some much needed rest.

The experience and features have been heavily updated. A few highlights to check out:

Heavily updated look and feel.
Multiple pages to help organize your content. Quickly rename and rearrange your pages (drag and drop them)
Adding content is much easier (and again, just drag an item from the list onto your page)
The coolest updated feature: Search (including extensible macros). Try the infinite scroller to move through the lists, click on the drop-down to find macros to extend your search experience.
Built in gadgets have an enhanced look and feel.

Explore. I am sure you will find more great stuff.

Talking about "The Real AJAX Upside"

Tue, 21 Feb 2006 05:26:21 GMT

Naming was never my specialty. Very little known tidbit. When I wrote the first DHTML draft specification, I named it "Active HTML" (I will leave it up to you to figure out why this is a bad name back in 1997). How did it change to "Dynamic" - from looking up Active in a thesaurus.

However, Dynamic HTML as a name served its purpose well in the late 90's. I do believe remarketing the existing technology as Ajax was a necessity for the community/ industry. Can you imagine all the new startups going for VC capital having to explain their cool new web innovations is based on 8 year old technology :-)?

Quote from Tim Bray's blog...

ongoing The Real AJAX Upside
"You know, I (Tim) could be excused for being a little bitter here. Everybody’s all gaga these days about AJAX as meme-ified by Jesse James Garrett. Check out Taxi to the Future, a piece I (Tim) wrote for XML.com in 2001, talking about how to improve user experience and system performance with a Transform-Aggregate-send XML-Interact architecture. Remind you of anything?
But you know, I’m actually not crying in my beer because first, Garrett was in the right place at the right time with the right acronym, and secondly, Scott Isaacs has been talking about this stuff since 1998 and helped invent most of the underlying technology, but dammit Scott, how could you ever expect to hit the memescape big-time with a dorky name like “Dynamic HTML”?"

Presentation: Creating Rich Interactive Web Applications Using Ajax

Tue, 07 Feb 2006 07:05:50 GMT

About 2 weeks ago (on January 25th), I gave a presentation on Creating Rich Interactive Web Applications Using AJAX. I just posted the deck at http://www.weblogging.com/decks/ajax.ppt. The deck is mostly intended for the attendees as the slides by themselves do not convey the full intent of the talk.

For those that missed the talk, I will be giving a similar talk at the Mix06 Conference in March:

Lessons from the Trenches: Engineering Great AJAX Experiences

Explore the challenges and lessons learned developing the Windows Live and Gadgets Web client frameworks powering Windows Live, Hotmail (Kahuna beta), Spaces, and more. This technical talk presents design and architectural considerations for building interactive AJAX-like sites. See how componentization, network management, accessibility, page composition, and more impact the design and engineering of your Web application.

The focus of the talk is to look well beyond AJAX to explore challenges in designing and engineering your web application. I believe the paradigm shift is not so much focused on AJAX (which is merely a development pattern) but rather around the ability to remix and mashup the web. The remix concept is fundamental to how we are architecting our experiences across Windows Live. This talk explores the web client technical issues that need to be considered when building a rich (remixable) web-experience.

Going on the road again...

Tue, 07 Feb 2006 07:03:57 GMT

Below is my schedule of upcoming conferences and talks.

Mashup Camp

Febuary 20th-21st

Computer History Museum in Mountain View, CA

To hang out, network, listen, and have fun :-)

O'Reilly Emerging Technology Conference

March 6th-9th

San Diego, CA

Presenting "Remixing the Web with the Windows Live™ Platform" (March 8th)

Mix06

March 20th-22nd

Las Vegas, NV

Presenting "Lessons from the Trenches: Engineering Great AJAX Experiences" (TBD)

Retiring the Spaces Cleanup Tool

Tue, 07 Feb 2006 06:57:17 GMT

Just as we were able to eliminate the Edit It Tool!, with the recent update to Spaces we can now retire the Spaces Cleanup Tool. The Spaces Cleanup Tool made it easy to quickly delete multiple comments and trackbacks from your blog. This feature is now natively supported by Spaces by selecting "Blog" when you are in author mode on your Space.

I am presenting at the WebGuild user group next week

Sat, 21 Jan 2006 19:15:51 GMT

If you are in the valley, feel free to join me Wednesday, January 25th, at the WebGuild user group (http://www.webguild.org). I am giving a talk on Building Rich Interactive Web Aapplications using Ajax. I will share design and engineering challenges that should be considered when building AJAX-like sites.

Other MSN/ Live Developer Developments

Fri, 16 Dec 2005 18:48:37 GMT

Two more interesting links...

Live.com

Steve Rider saved me a long post by posting the long list of enhancements with the latest Windows Live update. I suggest checking it out (http://microsoftgadgets.com/forums/1813/ShowPost.aspx)

Also, slightly old news, but Spaces released metaweblog API support earlier this month. You can find some details at Dare's blog and there is a MSDN discussion forum (http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=198&SiteID=1).

www.Live.com and Opera 9 Preview Support

Fri, 16 Dec 2005 06:13:58 GMT

We released an update to the Windows Live Home Page today with a number of changes and improvements around Gadgets (See Sanaz's blog for detail).

I believe one new feature is very much worth calling out.

The past few weeks, we have been talking to the Opera team on how to enable Live.com for Opera users (big Kudos to the Opera team for fantastic support). While not yet perfect, we have gotten much of www.Live.com working with the Opera 9 preview (we only validated against the Windows version). We are still working through some Gadget issues (e.g., the weather component does not work) but this is a big step forward.

Mix06 Conference

Thu, 15 Dec 2005 21:52:30 GMT

I promise I will get back to blogging more real soon :-)

I wanted to point out the Mix06 Conference. If you do anything web-related (e.g., Web 2.0, Ajax, etc) I recommend joining us for a conversation exploring the MIXed up world of the web. I will blog more about this over the next few months. I will be there most likely presenting and joining in on many of the conversations.

Talking about Trying to reward quick responses

Wed, 16 Nov 2005 17:10:09 GMT

Phil - thanks for contacting us. I have to hand Kudo's off to the Spaces team who agreed to prop the fix quickly to help our Firefox users. Every new browser release creates its own little challenges :-) and I am very happy to see the community helping in a positive way.

Quote

phil ringnalda Blog Archive Trying to reward quick responses

I’m not entirely sure that it makes business sense to always quickly respond to anything that any random person contacts you about, but it pleases me so much when someone does that I’d like to pass out kudos:
A couple of weeks ago, I noticed a bug floating past in Bugzilla saying that posting in MSN Spaces wasn’t working with recent Firefox builds (which was actually a duplicate of an early August bug that we’d just mostly ignored). Since I sort of approximately know Dare, I emailed him at a bad choice of public address, and then noticed that Mike Torres exposes his work email on his weblog, so I sent him an email too, at 6pm on a Saturday. Within half an hour I got a response, saying that he’d do what he could, though they were in crunch time. The following Monday, I got an email from Scott Isaacs, saying that they’d figured it out (despite my misleading claims about what the problem was, since I’m always wrong on my first guess) and the fix just needed to work its way out to the live site. I didn’t check every day, so I don’t know when it actually went live, but when I checked this evening, it’s working like a charm in 1.5rc2, with plenty of time to spare before people want to post about how much they like their brand new Firefox 1.5 on their Space.
Oh, the crunch time? This was the weekend before Windows Live launched. And belay that carping about the presentation: they’re programmers, not PR. Me, I’m impressed.

Talking about Ray Ozzie's New Blog

Wed, 16 Nov 2005 16:58:05 GMT

Nothing technical this week (heads down getting ready to go on vacation :-). I will be blogging very slowly over the next few weeks.

Ray Ozzie (Microsoft's CTO) has started a new Spaces blog. Check it out. (and before you ask, Ray has a "special" theme that is not available for us non-CTOs)

Quote

Ray Ozzie
When I first began blogging back in August of 2002, I explained that I was doing so to learn more about the nature of the link-centered medium, and that blogging might represent a new and more effective model of interaction in the "public space".
Indeed, I learned. Through two bouts of blogging - one lasting three months, the other about a year - I learned as much about my own communications rhythms and habits, stumbling blocks and compulsions, as I did about the medium itself.
A great deal has occurred since then......<read more>

Browser Support and Live.com

Mon, 07 Nov 2005 08:39:43 GMT

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:

Live.com to get Firefox support “very, very soon”

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).

UPDATE: I recommend also reading Sanaz's post on Live.com and Firefox.

Photo Album: Whistler

Wed, 16 Apr 2008 07:35:30 GMT

Whistler

Untitled Photo

Custom List: Other Sites

Thu, 01 Nov 2007 15:07:29 GMT

Other Sites

Scott on Wikipedia
A short bio about my inolvement helping define and create web technologies.
SiteExperts.com
A web developer community I have been hosting for 8 years.
Weblogging
If you can't remember my URL and need to get back - just remember Weblogging. http://weblogging.com!

Custom List: Partners in Crime

Mon, 24 Oct 2005 21:35:42 GMT

Partners in Crime

My Technorati Profile
MC
Spaces PUM
Jason
Spaces Dev Manager
Ryan's World
Spaces/ EFP Dev Lead
Jay's Krib
Spaces Lead PM
Mike's Blog
Spaces Lead PM
Sanaz
Start PM

Custom List: Gadgets for Start.com

Sat, 22 Oct 2005 21:48:58 GMT

Gadgets for Start.com

Multi-Search Gadget
Search for blogs on MSN, Google, and Feedster.
Feedster Gadget
A simple version of the multi-search Gadget that just searches Feedster.
Rumor City
Rumor City - Turns rumor city's RSS feed into a scrolling list.
Themer
Customize Start.com with your own style rules.