| | Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|
| 24 | 25 | 26 | 27 | 28 | 29 | 30 | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | | 8 | 9 | 10 | 11 | 12 | 13 | 14 | | 15 | 16 | 17 | 18 | 19 | 20 | 21 | | 22 | 23 | 24 | 25 | 26 | 27 | 28 | | 29 | 30 | 31 | 1 | 2 | 3 | 4 |
Search
Navigation
Categories
Blogroll
|

Tuesday, May 10, 2005

Sunday, May 08, 2005
Why Navigation Is *HUGE* In Avalon
I came across Chris Anderson's blog and he raised the question of "why did web navigation really add value?" This question really echoes the question that comes up from lots of briefings I've given on Avalon: "Why is navigation important in Avalon?"
One of the messages Microsoft has driven regarding smart clients and Avalon is that they combine the "best of Windows, best of the Web". Although I've never been a huge fan of that specific way of describing the benefits, it's definitely the most concise way of describing the goals: take Windows client programming (the *best* client offering in the industry) and integrate features of the browser-based programming model (often incorrectly referred to as "Web" programming) to provide something better than either independently. By the way, when I say "browser-based" consider a blanket include for HTTP and HTML.
While there are tons of sexy features coming in Avalon, my money is on navigation as the single most important feature. Sure, the MIL, simple 3D, styling, declarative design, great tools, interop, etc, are all cool, but navigation is what Windows client programming is most sorely missing today and will benefit most from in Avalon.
The benefits delivered by navigation support in the browser were really a happy accident. If you look at how the Web works, it's a "Web" because of the way you can hop from one site to another and criss-cross your way from anywhere to anywhere else. The integration isn't complex--it's basically HREFs, POSTs, and GETs. What these enable, however, is a way to write large systems to address business needs in such a way that they are really a set of smaller building block applications that can be glued together (often dynamically). The typical login functionality of any given site can be treated as a distinct application that has a set of preconditions and postconditions. Although you would be able to use it standalone, it would deliver little value on its own. However, you can still see some sites, such as Microsoft's Passport, that are able to offer authentication as a standalone service because the navigation support in the browser makes it that easy. The net result of all of this is that an end user can easily do whatever they need to, regardless of the underlying technology.
In contrast, Windows client programming today (Win32, .NET, J2SE, whatever) has a programming model that is much less conducive to integration.
First of all, browsers are great because they provide an easy way for you to build an app that never requires the user to leave the window. For client apps, there is no comparable support. The most obvious workaround is to recreate the current window to look like a different part of an app every time the user would "navigate" to use different functionality, which is something nobody wants to do. As a result, you'll find that almost every single app will require a new window in order to accept login credentials for an end user. Why is this? Partly because nobody wants to write and test the code that hides all the existing controls and replaces them with new controls just so the user doesn't have to deal with a new window. Windows also doesn't provide a way to replace the existing window's contents with a new set of contents without doing the work by hand. The closest thing is to use a wizard, but wizard support didn't make it into the .NET Framework. Even with wizards, they're not great for branching as much as a set of unique pages and a navigation infrastructure would be. Avalon will address this by providing a way to develop standalone pages within an app that you can navigate to and from.
Second, today's Windows applications are heavily "stack-based", meaning that there's no such thing as fire & forget with UI. Every event handler is like a clingy ex-girlfriend--they will need closure before you can get on with the rest of your execution. The transfer of control from one part of the application to another is tightly coupled to the internal implementation and the idea of having one app transfer data and control to another is all but impossible (the command line is the only thing that pops into mind). As a result, application UI components can be partitioned into windows/forms, but they're still not standalone components and are at the mercy of their caller. While browser apps are made up of individual pages that are pretty much service-oriented with the way they have very defined boundaries in their interaction with the end user, client windows in the same app are very tightly coupled and inaccessible to other applications. Navigation in Avalon addresses this by providing a clean break between different parts of an application. You can take a page and treat it as a standalone application (in many respects) and develop for it in the same way you would a Web page today. Unfortunately, I don't believe there will be support for integrating across applications in the same way, although I will admit that it's been months since I've spent serious time with bits and am very open to happy surprises.
Lately, I've spent a lot of time using Microsoft Money 2005. If you build smart client apps today, it is well worth your time to get a copy and play around with it. Although it obviously wasn't built using Avalon, I think it best represents the benefits early Avalon apps will deliver. The best part of the app--and perhaps the best indication of a smart client--is that you can use it whenever you want to and will always get the best experience available. If you're offline you can work off a local store. If you've got Excel installed, you can export to it. If you want to integrate data from online bank or credit card account applications, you can do it without having to leave the shell. Its homegrown navigation support is not used as extensively as I'd like, but it's very well done.
5/8/2005 4:56:19 PM (Pacific Standard Time, UTC-08:00)

Saturday, May 07, 2005
I Hate Rebates
I picked up a small switch last week to expand our network and accomodate more test machines. I had a choice between two functionally similar products, both from reputable manufacturers, although one was $20 cheaper than the other (after a $30 rebate). Trying to be fiscally responsible, I bought the one that was a better value "in the long run". As I went to fill out the rebate today, I noticed that the $30 was actually a combination of 2 rebates--from the same manufacturer--that each required the original UPC and could not be combined with any other offer. To top it off, they both need to be sent to different addresses, so it's not like I can lump them both together in the same envelope and let the rebate center sort it out.
Has anyone run across this? Is there some clever way I can screw "the man" back? The top suggestion will receive $40!*
*-checks will not be honored (heads-up, this is an *audio* link)
5/7/2005 4:42:02 PM (Pacific Standard Time, UTC-08:00)
Welcome Ezju (aka Edward Kranz) To The Blogosphere
Ezju, SharpLogic's graphic and design guru, has begun blogging at http://www.sharplogic.com/blogs/ezju. Among other things, he's been rebuilding our Web site, which will be up shortly. If you go to http://www.sharplogic.com and it still sucks, then his work hasn't been published yet.
Also check out his personal site at http://www.nosuchanimal.net where his paintings are available for sale. His coffee-based painting are truly unique--he uses coffee as the paint for the pictures (yes, I know I'm not doing the sophisticated process justice).
5/7/2005 11:27:20 AM (Pacific Standard Time, UTC-08:00)

Friday, May 06, 2005
Why I'm Against Some Discrimination Laws
I just came across http://www.msnbc.msn.com/id/7762073/ and saw that Microsoft's management has decided to unilaterally use the company's influence to support the bill, which will probably be useful to its proponents. There was a lot of controversy over this a few weeks ago (http://www.sharplogic.com/blogs/ed/PermaLink,guid,84ba33c2-8bb2-4ec8-8f3e-706bddb27295.aspx) and it's very interesting to see the company take a side now. Sadly, this derails a lot of credibility from Steve Ballmer's memo from a few weeks ago since this action directly contradicts the reasoning behind not taking a side. My guess is that Microsoft's management was blindsided by how big of an issue this would be and did research that determined the negativity from supporters of the bill greatly outweighed the negativity of those who did not support the bill, so changing the stance would result in a net positive. The saddest part of this is that some individuals will take credit for the "victory" (Robert!) because they know Microsoft will never divulge the actual reason for the flip flop.
I have very mixed feelings towards the bill. To begin with, I feel that if you're going to outlaw discrimination based on gender, race, creed, etc, then you must also include sexual orientation. Since there is enough clout in the state government to support those anti-discrimination laws, people with different sexual preferences should be protected as anyone else. There are obviously degrees to which sexual preference is still considered unacceptable regarding age and species, but that's not my focus here.
The part of HB1515 I strongly disagree with is actually not in HB1515, it's in some of the laws HB1515 is looking to amend. I am personally against state laws barring business discrimination. While I oppose discrimination myself and will never practice it, I believe that each business should be given the right to discriminate if it so chooses--for any reason. I hate the idea that I am not allowed to not hire the people I don't want to hire for any reason I want. For example, I may feel that an individual is highly qualified for a job after our interview. However, that person may belong to a religion that strongly opposes the idea of computer programmers, and is hell-bent on making their lives miserable. Unfortunately, as a business owner, my hands are tied! I *have* to hire that person because I'm not allowed to discriminate against qualified applicants purely based on religion.
While I am fully against business discrimination laws, I do feel that it would be appropriate for businesses and the government to require certain policies from their vendors. For example, my company does a lot of work for Microsoft, so having to provide proof that we are an equal opportunity employer would be a reasonable requirement. In the end, companies who choose to discriminate for the wrong reasons would be hurting themselves and would eventually die out to competitors who hire the best people for the job. Also, if a company is only hiring you because they're not allowed not to, then do you really want that job?
Just to reiterate--and avoid a misplaced flame war--I am completely against discrimination and agree with the essence of the bill. I just don't agree that the government should be unnaturally forcing something like this on businesses. The ironic thing is that I'm so against a law that I would actively obey even if it didn't exist.
5/6/2005 1:00:00 PM (Pacific Standard Time, UTC-08:00)

Thursday, May 05, 2005
.NET Framework 2.0 Beta 2 Install Note
If you're installing the .NET Framework 2.0 Beta 2 on an NT-based machine (NT, Win2K, XP, Windows Server 2003) then you'll need to have MSI 3.0 installed.
If you're installing the .NET Framework 2.0 Beta 2 on an 9x-based machine (98, 98SE, ME) then you'll need to have MSI 2.0 installed. This is necessary since MSI 3.0 only supports NT-based platforms.
You can figure out which one is installed by looking at the major number from [HKEY_CLASSES_ROOT\CLSID\{000C101D-0000-0000-C000-000000000046}\DllVersion].
5/5/2005 11:22:21 AM (Pacific Standard Time, UTC-08:00)

Wednesday, May 04, 2005

Saturday, April 30, 2005