Thursday, August 28, 2008

DevBlog: Why Vista is more stable than XP

I don't want to say much more to take away from Craig's great perspective here.

So some caveats:

1. I don't regularly run Vista - I want the right hardware to do so.
2. I don't like certain things about Vista - but then I don't like certain things about XP , or 98, or 95, or OS 10, or System 7 or ....you get the point.
3. Craig - this is what they should be doing instead of Mojave...yes, it's techy - but it explains it right. Kind of like the way Hybrid cars explain MPG better than Al Gore... or ...

I guess it's not quite so true tho...one ring to rule them all....

DevBlog: Why Vista is more stable than XP

Sunday, August 24, 2008

Get The SmallestDotNet

Scott Hanselman just posted some interesting details on the size of the .Net framework and I was surprised to see that it's really not as big as it always seems, based on typical installers.

Everytime you go to a typical DotNet download site, you see this "approximately 200 MB" download. Scary stuff if you're aiming to create a nice small download. But as he notes, this is because instead of creating a "pick the download that matches your configuration", Microsoft has an installer that covers every possible scenario, which unfortunately, DOES require 200MB.

So he's created SmallestDotNet: On the Size of the .NET Framework  - it didn't work so well on mine (as shown here):

<a href="http://content.screencast.com/users/Akselsoft/folders/Jing/media/fe8e9221-d9cf-4bf8-ad36-271a3051f694/2008-08-24_0425.png"><img src="http://content.screencast.com/users/Akselsoft/folders/Jing/media/fe8e9221-d9cf-4bf8-ad36-271a3051f694/2008-08-24_0425.png" width="405" height="166" border="0" /></a>

But it's better than nothing.

The only question that now arises is: but if I'm creating an installer, don't I have to be prepared for every possible installation? Possibly but apparently there's a tool "Client Profile Bootstrapper" that will make it easier in the future.

Note that this isn't for Dev DotNet stuff (like Team Explorer which is a 250MB download for what essentially is a file browser) - I wish there would be a similar post on this as well.

Great stuff and thanks, Scott!

Sunday, August 10, 2008

Demoing with Screencasts



After my post about screencasting (How to make Screencasting Made Easy AND Purposeful ), it was nice to see that Jason Calacanis also likes one key idea (based on his "how to demo your startup" email note.

His guideline: "the best products take less than five minutes to demo"

That post has lots of other great ideas for demos and they aren't just for startups - many established companies could benefit from this.

Tuesday, August 05, 2008

Olaf's Blogging

After what I would have to say was a great showcase of VFP Conference -tweeting , Olaf's started blogging...on one of his first posts, he shows how to do a Matrix-style screen in Cryllic, in FoxPro of course!

Welcome, Olaf!

Olaf's VFP Blog

Monday, August 04, 2008

How to make Screencasting Made Easy AND Purposeful

Everyone loves a good screencast, right?

You want to highlight your product or showcase a feature, so you start up your favorite screen recorder and record away. Then comes the fun part...the editing. Before you know it, a 15 minute screencast has turned into 2 hours of editing hell.

My personal torture tool of choice is Camtasia - which does a lot of cool features such as automatic zooming and panning and noise removal. But recently, I've talked about Jing - yes, it's by the same company (Techsmith) - but primarily as a screen image capture utility.

But this post isn't so much about talking about a product as it is about how to make these things easier. Whenever a great session is given at a conference, it's often because the presenter has done one of three things:
a) practiced
b) practising regularly  (if they were English)
c) rubbed their lucky rabbit's foot on a horseshoe after seeing a rainbow

In Screencasting, the same is true (well, except the part about the rabbit's foot - with screen casting, you just have to rub the top of the ...well, you get the idea). This is why people who regularly do screen casts smirk when someone says "just give me a 15 minute video" 30 minutes before a meeting.

But have you watched a 15 minute screencast? It can be painful. You're not watching Gone with the Wind or Braveheart or even a Discovery Channel documentary. If you've watched any of Scoble's video interviews, you know you have to be ready to bob and weave with the camera at any moment. Those are video interviews with some demos interspersed but usually, his team (of two) goes through the process of creating a shorter version to make it easier to interact with.

When you watch a great presenter doing an online seminar, after every 5-10 minutes of talking, they almost invariably do a poll or interact with the audience in some way. Even if it's just a way of making sure the poll-tracking features are working, it also serves to restart or re-enthuse the audience's attention span.

How can you do that in a 15 minute screen cast? I'm not sure you can. If you've got a topic that all of the watchers are absolutely enthralled by, then I don't think you need to worry but if you're trying to demonstrate part of your product or a cool tool, then I think it's best to come back to the old concept of "short is sweet".

So how does this relate back to Jing? Easy - Jing can only record 5 minutes of audio/video. Is that a limitation? Yes. Is it a GOOD limitation? I think so.

5 minutes means the following:
a) no fluffy white stuff (you will be forced to say what you want to say in exactly the amount of time you have)
b) you have to practice (so you can identify the fluff and rip it out)
c) No time for titles and special effects (hey - I like special effects but they can be annoying when I just want to see a feature)
d) Focus on the feature.
e) people who suffer from ADD may actually pay attention. (those of you with clients/bosses with ADD know what I'm talking about)
f) refactor your demo (see this post)

I'm a big fan of the Rapid E-Learning web site and a lot of it goes back to principles of adult learning, which forces you to think about things in terms of chunks and removing non-important details. One of the courses I took by FKA several years ago, spoke about breaking up your day into "review -> Learn -> Action -> Learn -> review" (or something fairly similar) and then how each TOPIC in your training could be done exactly the same way and if you were really good, you could bring this entire approach into every 15-30 minute part of the course. It's almost as if everything ever taught uses the conceot of the popular "I'm going to TELL you what I'm going to do, I'm going to do it and then I'm going to tell you what I've done".

If I've only got 5 minutes, it means that the real value of the screen cast has to be handled in 2-3 minutes, allowing for quick review or any brief explanation.

Since Jing ouputs directly to Flash, you also don't have the luxury of doing massive edits, which gets you (ok, and me as well - I'm as guilty as anyone on this) into a real good habit of preparing first, practicing second and then doing.

Here's a sample of one I did showcasing JiffleNow, a calendar scheduling tool I've been using of late (and yes, you can schedule time with me using this tool).

I still prefer Camtasia Studio for building proper screen casts but the idea of forcing actual feature demos into 5 minute chunks appeals to the purist in me. I started with the Jiffle demo but I think we can do more about these in making VFP easier to understand and use.

What do you think? How long is the ideal screencast for you?

Refactoring a Demo

I love refactoring code. Moreover, I think refactoring can also be used when looking at software demos.

I love looking at a piece of code that works (for the most part) but just doesn't feel right and taking it apart and putting it back together so that it makes more sense, not just for me but for the next person who comes along.

I find it funny that refactoring and unit testing come from the same core concepts (Agile) because if done correctly, code that was properly unit tested SHOULD result in code that is pretty well-written and refactor-proof. (I'm no expert on the philosophies behind this so please comment and rip this post to shreds)

So refactoring really comes into places where you've got unwieldy code (or worse, legacy code) that no one really can wrap their head around. By the time you've finished refactoring, you possibly COULD have some ways of unit testing it (if you were able to separate each logical piece out).

So how does this apply to demos?

Depending on who is giving the demonstration, a demo will consist of the following:

a) overview of features
b) description of benefits
c) demonstration of functionality
d) explanation of functionality
e) review of benefits / explanation of results
and possibly
f) showing of additional features

The actual content differs by person:
If a sales person gives a demo, it likely goes a->b->e.
A sales engineer: a->c->f->b (possibly e)
A developer: a->c->f->d (and sometimes you don't even need a)
A trainer: a->d->c
A trained user: c

If you want to really look at a valuable demonstration, why not refactor each piece of the demonstration asking the following questions (in this order):

1. What benefit are you trying to show?
2. What feature showcases this benefit the best? *
3. What is the bare minimum I can show to highlight this feature?
4. Is the result obvious?

* If more than one feature gives this benefit "best", then you may want to rethink the design.

How does this relate to refactoring code? Re-ask the questions, thinking about code:

1. What is this block of code supposed to do?
2. How could I rename this to make it easier for others to understand?
3. Have I made this as simple a call as possible for this function to run?
4. Is the result obvious to the calling program?

Development and sales departments almost invariably have a love/hate relationship. Turning some of the questions that are asked in both groups around to match the other's parlance might make a love-fest possible.

Are there any other areas that might benefit from "refactoring"?