Although Bill Gates says it won’t happen, here are 10 things I’d like to see if Microsoft would acquire Disney:
10. Free passes to Epcot Center for all MSDN Universal subscribers.
8. Windows ships with “It’s A Small World After All” as startup wav file.
7. Office Assistants Clippy the paperclip and Kairu the dolphin replaced by Grumpy and Sneezy dwarves. [“For crying out loud, you still need help with the mail-merge?”]
6. “Tomorrowland” attraction replaced with “Longhornland”.
5. “Honey I Shrunk The Kids Movie Set Adventure” replaced by “Windows Build Lab and War Room adventure”.
4. Wrong memo sent to Magic Kingdom security guards - incoming patrons inspected for buffer overflows.
3. The namespace System.Drawing.Animations.ToyStory
2. Free theme park advocates build the amusement park “Lisney”. Patrons disappointed when they need to edit /etc/lilo.conf with vi before gaining entrance to the “Rural Bear Jamboree”.
1. .NET Rocks! on the Disney Channel.
I finally put some time into Longhorn this weekend. At times I was a little bit frustrated (detail below), but overall the experience was exciting. Working with just what I had installed on the Longhorn Virtual PC, I decided to do a little Visual SourceSafe automation to display the file changes between two labels. Here is a screenshot:
If anyone is interested in the code I’ll be happy to post it up for download, but I would like to improve the app some (details below). At this point I wanted to play with some of the basic Avalon controls, including the GridPanel, and of course I had to try out a gradient fill.
(Update: Here is the code, just remember, no warranties express or implied, etc. etc.. Feedback and constructive criticism more than welcomed...)
Along the way I kept some notes on what I liked, what I didn’t like, and what I need to find out more about. I’m sure some of the problems I experienced are just alpha software glitches that will be fixed soon. These notes are not particularly focused on any specific area, but more general to the overall experience.
GUI design with XAML is going to be fun. Using XAML will bring some of the best parts of web design to WinForms while leaving behind all the restrictions. The idea of having a Style element to make sweeping changes to the appearance of a form is particularly powerful.
The refactoring features in Whidbey are worth the price of admission alone. The Extract Method and Rename commands are going to save untold hours of error prone work.
I find the task based documentation (How Do I?) in the SDK extremely useful, particularly when first delving into a new area.
I like the way the Internet Explorer menu and toolbar can occupy the same horizontal area. I’ve always set my IE toolbar icons to “small icons” to conserve space, but this is even better.
When doing a search in the Longhorn SDK (local copy), the “Location” for the search results always returns “Longhorn SDK”. When doing a search in the Longhorn SDK online, I can at least take a guess where I am going to end up by peeking at the URL. For instance, when looking for control documentation, the URL will tell me if I am going to end up in the MSAvalon.Windows.Controls area or the System.Web.UI.WebControls area.
The title bars are so tall they seem to waste space. At first look the contrast to previous versions is pleasing, but when I get down to work I’d like to have more space for real content.
After 20 hours or so of uptime, Internet Explorer (and dexplorer.exe) become so unresponsive as to require a reboot. Is this just me?
I’m starting to wonder what impact Avalon will have on the makeup of software development teams. These days, you can bang out a UI that competes with Microsoft Office applications (in terms of look and feel) as a solo developer. Taking a look at the Longhorn concept videos reminds me of the gaming industry. If you look at the postmortems for today’s best selling games – the skills required go far beyond bit twiddling. The teams usually have half as many graphic designers and artists as there are developers. Plus sound FX people, camera people, voice-over people, and an occasional composer.
Post build steps do not appear to function as yet in Whidbey.
It appears the automagic copying of app.config and COM interop assemblies does not function as yet in Whidbey. I also had some difficulties successfully referencing an interop assembly until I TLBIMP’ed it myself and added a reference by hand.
The app currently does all the work on the UI thread. I didn’t see an Invoke method on the Control class to marshal back to the UI thread, so I abandoned my plan to use a background thread for the VSS automation calls. I did notice the UIContext parameter on the control constructor, which is new, so I’ll need to dig around some more.
Databinding with the GridPanel control? The app currently builds the GridPanel from scratch in the C# code. The next step is to read more about databinding in Longhorn – I’m looking for something similar to today’s DataGrid in Avalon with sorting built in.
Is there an Avalon status bar control?
I’ve heard there is another version of Whidbey coming along soon to play with, but I’m also wondering when there will be another rev of Longhorn to experiment with. Overall - a fun experience with the new technology.
I went out this evening to vote in the Maryland primary. The voting machine was the somewhat controversial Diebold machine. After all the bad press I expected the machine to do something sinister while I was there – but alas – nothing extraordinary to report. No exit poll afterwards either. Bummer.
The only thing to note is the final summary screen which shows all of the selections. In some circumstances there must be a scroll bar present which comes dangerously close to the final “Cast Vote” button. There is a caution at the top of the screen in a small light blue font saying something like “Don’t accidently hit submit when using the scroll bar.” Seems like something they should design around - particularly when there is no confirmation after hitting the big green button.
Dana Epp points to an Internet News article stating XP SP2 will include a virus scanner. I can see the controversy coming, as many people will be unhappy about MS bundling more software into the operating system.
Let’s face it – anti virus as an add-on product just doesn’t work. When someone walks into BestBuy with $50 to spend, I’m sure the products like Halo move much faster than any anti-virus software. It’s just not human nature to spend money on something preventive when you can buy something fun. Halo has much better graphics then any anti-virus software I've ever seen - the choice is obvious.
Here is a new article demonstrating how to use the web service API of Reporting Services to build a tree view of reports available to a user. The ASP.NET project also hosts the ReportViewer sample component in a page to display reports.
Friday was one of those days when I didn’t get to sit at my desk till 2 in the afternoon. What was supposed to be a quick overview of upcoming requirements became an embroiled strategic planning meeting. I came out thinking: how scalable is our software?I wasn’t thinking of scalability in the sense that Sam Gentile was recently thinking about scalability. I was thinking that given the architecture and feature set of our software, how many clients can our small startup support? Since I am probably as clear as mud, let me give you a scenario without too many boring details. We built an ASP.NET Intranet application. The application uses Active Directory. By using AD we saved ourselves development time in building the administration areas of the application. On Wednesday of this week, a prospective customer and his technical team call me. They don’t use AD and have no ready plans for migration. They are using NT4 and are not buying our software if it requires a move to Active Directory. Nevermind that the clock is ticking on NT4 support options. One of our options at this point is to rip out code relying on Active Directory and build it ourselves. I don’t like this option one bit – it’s not a one time cost. There is an ongoing cost in maintenance, regression testing, deployment, end-user training, and support. It limits the ability of our company to scale up sales, because the cost per client just went up. In a small startup company it’s difficult to approach the CEO and sales team and tell them why making a sale is a “bad thing”. The engineering team appears mean, nasty, inflexible, and unsympathetic to customer needs. Believe me, I am sympathetic to what the customer wants. One of the benefits of a small company is having hands on contact with the customer. When they get excited about something I’ve help to create I get excited too. When they want something new I want to build it for them, but I know a company has to live within it’s means. If you build software that is difficult to install, and configure, and support, be prepared to make a living by billing time and materials. I’m sure there are application domains that have no other option, but just make sure you go in with the proper business plan. I try hard to resist customized features, or requirements that make the software more difficult. Unfortunately, in small companies it is very hard to resist cash. Ironically, what helps in big companies can help even more in small companies where resources are tight and people wear different hats. The two biggest process related tips I can give are 1) Have a software development process in the first place, and, 2) automate ruthlessly. Use automated builds, and as much automated testing as possible. It takes more time up front, but pays dividends many times over as time goes on by leaving less to manual intervention, and therefore chance. It also keeps you scalable.