November 2003 - Posts
I went to the PDC. I got the bits. I played with Whidbey and ASP.NET 2.0. I fell in love.
Back in the real world of work, I'm about to start a 4-6 month project. During this project we'll have to:
- Use (or write our own) a page templating solution that will allow a consistent look and feel across the site with minimal effort per-page. Hmm, master pages would be perfect
- Allow personalization. Hmm, doesn't asp.net 2 have a personalization engine?
- We'll use objects as data sources. Unfortunately our interns will have to forgo the use of the designers because they don't support this at design time. Hey, doesn't whidbey have an object datasource?
We'd like to:
- validate against XHTML. Not going to happen with VS2003.
- pre-compile the huge number of pages / ascx's this project may have to catch compilation errors before the page or code-path is hit. Wish I could do this
Yikes- I want Whidbey! Now!. I can get lots of this now from different or home-grown solutions, but in 9 months or a year when this application is re-visited, I'll be using Whidbey. Wouldn't it be great if I didn't have to
- Spend time now hacking together what whidbey already has in the alpha?
- Not have to rewrite the code later to use whidbey features? (or support both?)
So here I am, reimplementing things that Microsoft has already built, grumbling because I can't use it. This doesn't even touch the other things I want (generics, refactoring, stencils, other “neat“ features)
I don't understand why people would want to consult a psychic - It sucks to know the future when you're stuck in the present.
Rebecca Dias let us know of a change to WSE2 based on PDC feedback:
We have already taken one action in WSE v2.0 as a result of the feedback from the PDC. Attachments will be abstracted away so that migration to MTOM will be more seemless.
This makes me very happy in two ways:
Despite letting us know that adopters of WSE are on the “Bleeding edge”, and should expect more work when migrating from one version / messaging technology to the next, they're still making it easy on us. Attachments are one of those things that we want now, and WSE is for people that aren't afraid to pay later for doing it now. Thanks for making us pay less. Ahh, SWA & DIME, I hardly knew ye.
She cares! she really cares! -- I mean, of course, that Microsoft cares. One of the biggest lessons I came away with from the PDC was that I am Microsoft's customer, and I'm important to them. Too often, people think of MS as the “evil monopoly” that simply churns out standards-breaking software, and those of us that use that software have to sit back and watch for whats coming next. Not so. Microsoft knows that by listening to me (yes, me and others like me) they are better able to a) build better software, and b) keep making money by being the platform/tool vendor of my choice.
One other thing the PDC helped me with - I stopped thinking of Microsoft as “that software company”, and started thinking of Microsoft “that company where lots of people work to make software”. Perhaps a subtle disctintion to most of you, but to me the personalization made a huge difference in my mindset about why they make some of the decisions and products that they make.
That's right - the same bits of Longhorn preview available at the PDC are now available to download
(MSDN subscribers only). I guessing slowly, as everyone in the world hits the servers at the same time.
Okay, So Jeff Key found the folder containing expansion files. How do we make our own expansion stencil files and get them to register in with Whidbey? Am I an idiot, or does this not work yet? (Yes, I know, two separate questions)
Also, can anyone tell me what the heck “Activate M2.5 Features” means under “Code focused development” in the VS options dialog? (Go to Tools | Options, select Text Editor | C# | Miscelaneous). The help for this option property page states (and this is the full text, other than the “pre-release documentation“ disclaimer and useless see-also links)
The Miscellaneous property page, in the C# folder of the Text Editor folder of the Options (Tools menu) dialog box contains the following properties:
Yep. That's it. Almost as helpful as the “How-To” on creating your own expansions for VS.NET Whidbey (see Jeff's post)
Due to quick feedback (out of band) about size and relevence to .net, I have moved my response to this post from Critical Section to a “story“. You can find it here. Sorry to those that saw this in the aggregators.
Many people have seen the new Avalon UI paradigm, and the ease with which one can "skin" an Avalon app. Many of those people are concerned (rightly, I think) that this means that every app out there will depart completely from UI standards that we all know. Lately, I've been asking myself - is that a bad thing, or a good thing?
You can ask anyone who knows me (if you can find anyone to admit it); I have some strong feelings on UI design and consistency. I've gone to the mall management office when a pull door had a horizontal push-style bar to complain0. I hate analog watches (I mentally translate the position to numbers anyway - why not show me the numbers?), and I've quit using applications that annoy me because they depart from windows standard UI behavior in ways that make it hard to use the application ( a push button is not a drop down menu! - I'll live with the little down arrow part, but the whole button?).
Now, seeing what Avalon is capable of and what it makes easy, I wonder - is non-uniformity1 a blessing in disguise? Let's examine why consistency is good:
- A user interface that conforms to the expected UI guidelines lets a user spend less time thinking about how to interact with your application, and spend more time thinking about what they want to do with your application.
That's pretty much what it all boils down to. It keeps the user from having to think about the how, giving them more brain to focus on the what.
Can we accomplish this goal another way? With a great design, couldn't we use the freedom that Avalon may give us to make our interface functionality intuitive? I think we can. Why would I want my spreadsheet to have the same UI as my contact management software? They do different things - why present them the same way?
My toaster is intuitive. It performs a simple function and has a simple interface. My microwave oven is intuitive for simple timed cooking2 - press the time, hit start - but it has a completely different UI than my toaster. They perform different tasks, but accomplish similar things (heating of food), and I use them both equally well (even though I only use my toaster once a month). Is it really wrong to start writing applications this way?
I'm not yet convinced that we should start removing consistency guidlines. But I think back to the demo app given during the keynote at the PDC (the legal case management application), and see that it can work. It can work very, very well with a UI designed from the ground up for the task at hand. I can't wait to see the future. Perhaps Longhorn Evangelists can post some demo apps (like this one) for us to see and believe - I know I'd like to see what the designers of Avalon think are possible.
The other thing I can see is this : if you're wondering what career path to take for the future, designer will be a good one.
0 Perhaps it was because I think mall UI should be consistent. Perhaps it was because I ran into the door and had to abate my embarrasment by blaming others. I'm going to say it was the former. 1 Okay, so maybe non-uniformity is not a word. I like it, and I'm using it.
2 For programmed multi-step cooking it's not so easy. And it still can't fix the main problem I have - failing to read directions on frozen foods.