John Nack makes an extremely rational and systematic analysis of how many voices on the Internet consider Adobe to be the Devil. Is Adobe and in turn Flash Player the antagonist of all that is good about the web? Are they set to destroy the evil proposed Html 5 standards because they might compete with Flash Player?

Read and ponder.

Sympathy for the Devil

Honestly, I eat maybe 1 or 2 beef cheeseburgers in a year (and I don’t even care for most cheese!). Regardless, I still thought this web site, Cheese and Burger Society is really well done (pun not intended!).

It uses Adobe Flash, but really to good effect. There’s a voice over for each recipe.

“Number 7… it’s not for the guy who makes spreadsheets for a living.”

“Limburger, I once fought off three hungry bears to protect my Limburger. True story.”

There are interesting cheese facts:

Famous for its pungent tendencies, this brave and bold Belgian cheese does nothing but intensify with age. Limburger was created to complement the highly flavored meats commonly eaten in Belgium and Germany. Today, a single cheese plant in Monroe, Wisconsin produces all the surface-ripened Limburger made in the United States.

(Monroe, Wisconsin is relatively close to the WiredPrairie homestead.)

I’m using a progress bar in a small WPF application I’m working on and noticed that the Private Working Set for my application seemed higher than I expected.

My application, once simplified down to it’s most basic element, consisted of:

Window, Grid, ProgressBar

On my Windows 7 x64 machine, running the application uses around 29MB (private working set).

Removing the animation only from the visual template drops the private working set to 19MB.

So, it appears that the animation alone causes an extra 10MB of private working set to be needed. Sorry, but that’s crazy (especially for my application)!

If anyone has any specific theories – speak up! Here’s the basic starting Window I created:

<Window
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:Microsoft_Windows_Themes="clr-namespace:Microsoft.Windows.Themes;assembly=PresentationFramework.Aero" x:Class="PerfProgressBar.Window1"
    Title="Window1" Height="300" Width="300">
    <Grid>
        <ProgressBar x:Name="progressBar1" Value="100" />
    </Grid>
</Window>

I’m not going to post the entire ProgressBar template, but if you want to reproduce the problem (and see how the animation impacts the memory requirements, just comment out the “Animation” rectangle in the control template (and in the trigger as well):

<Rectangle x:Name="Animation" Fill="{TemplateBinding Foreground}" Grid.ColumnSpan="3" Grid.RowSpan="2">
    <Rectangle.OpacityMask>
        <MultiBinding>
            <MultiBinding.Converter>
                <Microsoft_Windows_Themes:ProgressBarHighlightConverter/>
            </MultiBinding.Converter>
            <Binding Source="{StaticResource ProgressBarIndicatorAnimatedFill}"/>
            <Binding Path="ActualWidth" ElementName="Background"/>
            <Binding Path="ActualHeight" ElementName="Background"/>
        </MultiBinding>
    </Rectangle.OpacityMask>
</Rectangle>

<Trigger Property="IsIndeterminate" Value="false">
    <Setter Property="Fill" TargetName="Animation" Value="#80B5FFA9"/>
</Trigger>

Apparently, the ProgressBarHighlightConverter is intense (a little double checking in Reflector confirms!).

(All animations have some price of course – as an experiment I rotated the progressbar in a storyboard and that used about 7MB).

The moral of the story here really is to make sure you do some sanity checks against your [fill-in-the-blank] technology so that you understand how it uses system resources such as memory, CPU, etc, as it may have an impact on the success or failure of your application. I’ll leave out the gratuitous animations in my application so it doesn’t use memory unnecessarily.

If you’re using the Microsoft Ajax Library (learn), you may not always want to start the automatic “attach” process that takes place when the page loads. It’s easy to disable, but not yet documented any place I could find easily.

<script src="Scripts/MicrosoftAjax/Start.debug.js" type="text/javascript"></script>
<script type="text/javascript">

    var ajaxPath = "";

    Sys.activateDom = false;

All you must do is set Sys.activateDom to false as shown above (make sure this is set after the new Start.js JavaScript file loads, otherwise your code will crash when you try to set the Sys object before it has been properly constructed).

Then, to begin the attach process, just call Sys.activateElements:

Sys.activateElements(document.documentElement);

In the code line above, though I’ve specified that I want the entire HTML document activated, you could provide any element you want as a starting point (for example to optimize the use of the library and prevent unnecessary DOM searching for example).

I’m adding the delay in some JavaScript code because I wanted to set up a few variables in advance of the attach occurring. I tend to write my JavaScript code in an object oriented fashion these days (using the prototype pattern), including code that is interacting with the DOM. In this case, I’ll create a class that represents the logic of the page rather than following the typical purely functional model that is done on many JavaScript pages. But, when using the “eval” syntax of the Microsoft Ajax library “{{ code }}”, occasionally, I’ll need to delay the eval or the page will crash.

From my recent post on making a simple command extension to the Microsoft Ajax library, I wanted to make that more object oriented by referring to an instance of my class, rather than pointing directly to a function:

<body sys:attach="wpc"
    wpc:onbubbleevent="{{$view.onCommand}}"
    xmlns:sys="javascript:Sys" xmlns:wpc="javascript:WiredPrairie.Commanding">

$view represents the instance of my page’s behavior. However, if the attach were to occur too early, this variable is not yet set. I’m using the slick script loading functionality of the ajax library, specifying the various JavaScript libraries and their dependencies, including my page’s behavior. It’s not until that JavaScript code is loaded that the code can create an instance – and that could be AFTER the page has already done the attach logic. The attach happens before Sys.onReady for example. (Sys.onDomReady happens before onReady, but not all JavaScript files may have been downloaded).

Sys.onReady(function() {
    $view = new WiredPrairie.MainView();

    Sys.activateElements(document.documentElement);

When using the sys:attach attribute, note that the attach and instantiation process happens before any code you’ve specified in onReady is executed (Microsoft currently uses the same method for determining when everything is ready by adding a function call to onReady – but their call is first in the queue).

Jeffrey Carver has provided a number of his science fiction books for free on his web site here. I’ve just completed reading the free Chaos Chronicles series (books 1-4) and enjoyed them quite a lot. Each book isn’t very long, so it’s easy enough to get through the series without drowning in sci-fi tech details.

My only “new year’s resolution” this year was recorded on Twitter thusly:

So, I just threw some money in Jeffrey’s tip-jar as a thank-you for the e-books. I’m sure it was more $ than he would have gotten directly from me if I had purchased the physical books from a reseller like Amazon.

Amazon has the fourth book in paperback at $7.99: Sunborn (Chaos Chronicles)

If this isn’t a head-slapping coding-moment I don’t know what is…

Encryption busted on NIST – certified Kingston, SanDisk and Verbatim USB flash drives

The crack relies on a weakness so astoundingly bone-headed that it’s almost hard to believe. While the data on the drive is indeed encrypted using 256-bit crypto, there’s a huge failure in the authentication program. When the correct password is supplied by the user, the authentication program always send the same character string to the drive to decrypt the data no matter what the password used. What’s also staggering is that this character string is the same for Kingston, SanDisk and Verbatim USB flash drives.

I can’t imagine the security firm SySS’s reaction when they found this:

Analyst 1: “Ah Houston, we have a problem here. Dudes, this thing isn’t secure at all. It doesn’t even use my password for the encryption!”

Analyst 2: “Get the #$@!# out!! I’ve got 4 weeks scheduled to look at this thing. It’s day 2. No @$%!@# way.”

Analyst 1: “Seriously. It data is always encrypted with the same string.”

Analyst 2: “Cool, I get the next 4 weeks off.”

There may be another way to accomplish this, but I wanted to have a simple commanding system in the Microsoft Ajax Library which worked outside of the templates.

After a number of false starts and frustration brought about by very limited documentation, I discovered a reasonable implementation.

I created a script file, “Commanding.js” (in a Scripts folder):

/// <reference name="MicrosoftAjax.js"/>

Type.registerNamespace("WiredPrairie");

WiredPrairie.Commanding = function(element) {
    WiredPrairie.Commanding.initializeBase(this, [element]);
}

WiredPrairie.Commanding.prototype = {
    initialize: function() {
        WiredPrairie.Commanding.callBaseMethod(this, 'initialize');

        // Add custom initialization here
    },
    dispose: function() {
        //Add custom dispose actions here
        WiredPrairie.Commanding.callBaseMethod(this, 'dispose');
    }
}

WiredPrairie.Commanding.registerClass('WiredPrairie.Commanding', Sys.UI.Control);

if (typeof (Sys) !== 'undefined') Sys.Application.notifyScriptLoaded();

This is just a basic JavaScript class, with the default implementation provided by the Ajax Client Control template in Visual Studio 2008. The reason this is needed is that Controls all support a special event onBubbleEvent that is needed by commands when they’re raised.

In the body of the HTML, I attached an instance of the “WiredPrairie.Commanding” class to the body. Next, I attached a JavaScript function to the onbubbleevent (wpc:onbubbleevent, remember that all attributes need to be all lowercase). Here, I’ve used the special {{ }} syntax to indicate I want JavaScript code to execute when the event is raised.

<body xmlns:sys="javascript:Sys"
    xmlns:wpc="javascript:WiredPrairie.Commanding"
    sys:attach="wpc"
    wpc:onbubbleevent="{{onCommand}}" >
    <div >
        <button sys:command="startRunningCommand" sys:commandargument="iargueaboutit">Run</button>
    </div>
</body>

I needed my JavaScript WiredPrairie.Commanding class to load and run at the right time on the page, so I’ve used the new loader classes in the Ajax library.

Sys.loader.defineScripts(null, [
{
    name: "Commanding"
    ,releaseUrl: "Scripts/Commanding.js"
    ,debugUrl: "Scripts/Commanding.js"
    ,dependencies: ["ComponentModel"]
 }
 ]);

First, I needed to declare this new script file and any dependencies. Since I don’t yet have a minified version, I’ve just specified the same file for the releaseUrl and the debugUrl. For the dependencies property, I looked through a few source files to discover that the “ComponentModel” key included Sys.UI.Control, which my class depends on to be created, so I added that here (hopefully this will be documented at some point).

Next, I added code to indicate to the loader which scripts were necessary and let it determine the best way to load them:

Sys.require([Sys.components.dataView, Sys.scripts.jQuery, Sys.scripts.Commanding]);

Here, you see the “Commanding” key is added to a special namespace, “Sys.scripts.”

In the new onReady event which is raised when the DOM and scripts have been loaded, I’ve added code to activate the control class I wrote:

Sys.onReady(function() {
    Sys.activateElements(document.documentElement);
});

Finally, I wired up that event declared above in the onbubbleevent attribute on the body element.

function onCommand(sender, args) {
    if (typeof (args) !== "undefined") {
        var commandName = args.get_commandName();
        var commandArgument = args.get_commandArgument();
        alert(commandName + " " + commandArgument);
    }
}

OK, that’s cool, but you might want to raise a command without it being triggered by a control event (such as a click). So, I added a simple function to my Commanding class:

WiredPrairie.Commanding.raiseCommand = function(sender, commandName, commandArgument, commandSource) {
    var source = sender || document.body;
    Sys.UI.DomElement.raiseBubbleEvent(source, new Sys.CommandEventArgs(commandName, commandArgument, commandSource));
}

var $sendCommand = WiredPrairie.Commanding.raiseCommand;

Because of the way the raiseBubbleEvent works, it does depend on the source being set to a valid control/element (as raiseBubbleEvent walks through the parent chain until there aren’t any more parents) – in this case, I’ve defaulted to the body element.

Finally, an enhancement to the test case above to demonstrate both receiving and sending a command:

function onCommand(sender, args) {
    if (typeof (args) !== "undefined") {
        var commandName = args.get_commandName();
        var commandArgument = args.get_commandArgument();
        switch (commandName) {
            case "startRunningCommand":
                $sendCommand(null, "alertCommand", new Date().toLocaleTimeString(), null);
                break;
            case "alertCommand":
                alert(commandArgument);
                break;
            default:
                break;
        }
    }
}

One command just sends another command which displays an alert. It’s simple, but functional.

Enjoy.

“The ten principles that contribute to a Googley user experience.”

1. Focus on people – their lives, their work, their dreams.
2. Every millisecond counts.
3. Simplicity is powerful.
4. Engage beginners and attract experts.
5. Dare to innovate.
6. Design for the world.
7. Plan for today’s and tomorrow’s business.
8. Delight the eye without distracting the mind.
9. Be worthy of people’s trust.
10. Add a human touch.

Definitely read the full details here:

http://www.google.com/corporate/ux.html

I’ve enjoyed following the thought pattern of Stephen regarding the major iteration of the Firefox user interface and experience here. This latest post walks through the general clean up of the title bar, menu bars, address bar, and bookmark bar in Firefox.

I must say that the new proposals for Firefox finally take the UI from a all-too typical layout to something modern, hip, and clean. A web browser should not interfere with the one task it is intended to perform: view and interact with web pages.

For normal browsing (and not development) I use Google’s Chrome browser nearly exclusively, and when I don’t use it, I switch to IE 8. That combo works well enough (and best handles sites that are more IE friendly than they are web-standards friendly).

I particularly like Chrome’s clean approach to full screen web browsing. Admittedly, having more than a couple dozen tabs open tends to make the tabs a bit unwieldy (I’ve got 44 tabs open in Chrome right now).

Compared to Firefox (one of the proposals and the current 3.5 shipping UI), the proposals definitely modernize the user experience of Firefox, yet not quite maximizing the web application experience like Chrome does so well (Firefox images grabbed from Stephen’s web site):

I’m not sure that the orange Firefox button is really necessary though for the average user (at the cost of a significant amount of horizontal and vertical pixel-estate). What kind of actions would users expect to find there? But more importantly, what would the UI for the drop down look like?

It would be a big failure if it was nothing more than a cascading drop down menu, for example, like I’ve configured in Firefox 3.5 with some extension who’s name I’ve forgotten.

Overall, I do consider this progress though, and appreciate the transparency of the design process with the next version of Firefox.

And I, unlike some of the commenters on Stephen’s blog, feel like it’s more important to make progress rather than be artificially held back by old designs, and not giving into lots of options and configuration choices which cater to vocal groups (so that they can never change). In this case, I’d follow Apple and Google’s lead (and even Microsoft’s to some extent when it comes to applications):  make it good, make it simple, don’t put it lots of bells and whistles and don’t make it too configurable.

This was one scary Santa seen at a Von’s grocery.