We’ve all seen the Courier speculations… if you haven’t go look here for some new info or watch this Video:

I have basically been trying to emulate this functionality on my tablets PCs with very little success ever since I got one…

So what makes this different and unique from something like the iPad?  First of all its Pen Based, the iPad is touch based and doesn’t even have an option of a pen. So that begs the question, if I have Multitouch and a virtual keyboard do I even need a pen? 

UNEQUIVOCALLY YES!

I am far more comfortable using a pen for quick notes and drawing than I ever will be with my finger.  I can’t write text like finger-painting.

Circle/Cut/Drag/Paste/Annotate is exactly what I need to do most and if you watch the video above you will see that this is exactly the target of the Courier.

I want something small enough to carry without being cumbersome, with enough journal type functionality it can stand on its own.  I want to carry this IN ADDITION to a phone (which is too small to be practical) and a powerful notebook that I will use mostly for Developing Software.  I already carry two notebooks, but one is almost never used: the Acer 1420P which turns out to be a HUGE disappointment in functionality, it has every radio known to man, which is great, but the pen is a joke and the touch is resistive and leaves a lot to be desired, I may give this to one of my kids.

Convergence will never happen, I gave up on that a long time ago, segregating what I do on 3 different devices makes perfect sense. 

1.I want a phone that also lets me read an email, send SMS, Display Maps and do a quick browse of the internet.

2.I need a laptop powerful enough to write software, but is generally to big to whip out for meeting notes, or brainstorming… in fact it won’t be a Tablet.

3.Lastly I need something to organize my Mindmaps, Notes and Sketches for general work, this is where the Courier would fit perfectly.

Originally when I first saw the iPad I thought it would work, but I need a PEN.  I also need expansion or at least the ability to save things externally.  I don’t want to connect my device to a PC to sync stuff, it needs to stand alone.

Why the Courier can change everything…

First I have to assume it is a fairly open model like the Windows Phone 7 Series will be which uses XNA and Silverlight as the development platform.  We can assume that since they run the same OS on the courier, developing will be the same.

Secondly, and this is vitally important, is that Steve Ballmer just said that by the end of the year 90% of all Microsoft Employees will be working on Cloud solutions.  This is critical because one of the biggest problems I have with OneNote is syncing.  Currently I use Mesh, but that is not really optimal for the purpose and is limited to 5Gigs, a large capacity drive in the cloud completely solves this, but it MUST interact seamlessly with all my devices, this is where things like AWS fall down.  No one is going to install Sharepoint just to sync OneNote files, well I did once and gave up because it was too much of a hassle.

I want to be able to send my wife a OneNote notebook of a trip I am on so she can see it, do some editing and send it back.  Currently this is agony to pull off.

I need a damned Calendar that syncs properly to every device I have, maybe this will get solved in the next release of Office, but I am not holding my breathe.

This plumbing is the sort of stuff no one wants to think about.

Give me a few hundred gigs in the Cloud, a Phone that does simple things in my pocket and a Notebook that actually works well with Pen and Voice, connecting to a 3G network, has at least an 8 hour battery life and doesn’t require a nuclear power pack to run, this is what I see the courier doing for us in the next couple years.  I certainly need a fairly powerful machine for development and I don’t want to pull that out every time I need to check my journal.

I typically have always tried to "think outside the box." It's something my father taught me to do…

He said: "When you feel trapped, you are probably only seeing the possibilities that exist inside the box you are trapped in."

What he meant was that if I am enclosed in a box, then I only see the 6 walls of the box. 

Imagine if you will that you wake up are truly trapped in a box, it’s dark and you don’t know how you got here.

I feel around and all I perceive are what appear to be 6 solid walls, there are no windows, no door, no openings at all in which to escape.  So how to I get out?  I don’t know that the box is just cardboard and I can probably just punch a hole straight through the wall… But, this would also mean destroying the box.  Now we start on a journey of exploration to find a way out.

I push up on the ceiling and the box opens, the ceiling is not actually solid, but rather folded over as to look solid but really isn’t; I have just escaped without destroying the box. XYZZY.

Yes, this is just a simple analogy and not really “The Box” I want to talk about.

Software development is a tricky thing.  Many, many very smart people have created many things that we use every day to get a job done.  These are very similar to the box I just described above; they lack documentation(in the dark), they are incomplete(no door), or they just work differently than we want to(the maze).

Do you feel trapped in your development? I know more frequently than not, I do.

• When I am programming in a specific language, I feel trapped by the language.
• When I use a Framework, I feel trapped by the Framework.
• When I use a "3rd Party" tool, I feel trapped by it's limitations.
• etc., etc., ad nauseum

These are all in their own right, boxes.  They are boxes of ideas that someone created to assist in crafting software.

Lets take that a step further:

Facebook is a box, it’s a container that can import an application based on some contract.  It’s very popular because it is useful for telling all your friends about something without having to call each one of them and repeating the news.

iPhone is a box, it’s a Swiss army knife for communicating and it imports useful applications.

XBox is a box that plays games and does some other interesting things, it too can import useful applications.

In fact, a Browser is a box too, it imports these things we call URLs that might be some text, a picture, or even a guided application to do useful work.

THESE are all “The Box.”

We are trapped in them, when I am writing something that is useful in one box, it’s not necessarily useful in another.

Alright, so who cares.  I care.  I care because the way we are writing software is all wrong.  It’s wrong because we are stuck in the mentality of “The Box.”

So what can I do about it?  I’m just some guy with yet another opinion of how it should be… but isn’t.

Maybe, but I am also someone who needs to get his job done every day.

Enough Philosophy, get to the meat.

What if we could create software in such a way that gets rid of many of the limitations of our boxes?

How do I avoid just creating another more elaborate box?

We can, and we will be discovering and re-inventing exactly what that means over the next several years.

Java coders hate C++ coders, C++ coders hate C# coders, C# coders hate VB coders, and the Ruby coders just think they are better than everyone else :-)

Can’t we all just get along?  Probably not, but this is the world we live in.  Everything is divergent. Its going to stay divergent so we just need to find a way to work within those boundaries.

One thing I do know is that if you live and work in a Microsoft Technology world, there is some help for you within that quite large world of development.  This is “The Box” I am going to be focusing on.

Typically, we are writing software that follows some pattern or another that is sometimes referred to as a “best practice.”  Most of these “patterns” come from the Java world not because Java is the best, but simply because academics who write this kind of stuff decided they would use Java.

So can’t we have some patterns that are our own?  Of course we can and the first of those patterns I am going talk about in my next post is “Composability”. Hopefully you know what “Inversion of Control” and “Dependency Injection” are and what purpose they serve.  I am not going to go into describing them much more than to say, they are great for things you know everything about.  For things you know nothing about, not so much. Composability doesn’t really have much to do with this, except that to get it, you don’t need IoC/DI.  Closely related to Composability is “compositionality.”

The idea of “The Box” is that it’s a trap and what I really want to do is introduce you to a methodology that reduces the possibility of really getting trapped.

Inversion of Control is all about reducing the procedural nature of programming.  When I started programming, we wrote programs that started and ended in a line by line step of procedures.  This is procedural programming and for the most part, we are still doing it. We have reduced the amount of procedure to a smaller set of steps, but in fact, it’s still procedure mentality.

Dependency Injection is all about decoupling one part of a software from another.  This means that if I have two procedures, they don’t depend on each other for my application to function.

Yes, this is the skeleton of what IoC/DI really mean, but that all we really need to know.

My goal now is for all software to become Composable and have compositionality.

How can I achieve this “Holy Grail?”  I use the grail analogy, because we can’t at this time start on the quest to find the solution for everything. 

The constraints of my box:

My box is going to have the following constraints:

We write software using the .Net Framework.

Wait, That’s it?  What about Silverlight, Web, Windows or whatever choices we make?

Yes, those too add some limitations that may be unique to some of your needs, but the style of writing and the methodology is the same, this applies to them all.

But IoC/DI is all the rage!  Why would I abandon those?  I’m not saying you should.

I am focusing specifically on writing NEW software, if you need to conform to anything legacy, you can write the new stuff with this methodology and still use it inside a box that contains your IoC/DI limitations.

Alright, next constraint.

We will be using MEF, the “Managed Extensibility Framework” and the Reactive Extensions for .Net.

Yes, these are new, they are not for everyone(yet). If we start designing and thinking outside the box of what we have been taught for so long, you may start to see there is a way to break some of the chains that have constrained us elsewhere for so long.

I really look forward to digging into this and hearing your feedback about both the patterns and the idea of composability which will just change the way we think about writing software in the future.

We will start simple, we will be building a Framework from the ground up using this methodology one piece at a time and looking at how each part works so we can apply it to our own business needs.

This is probably one of the most important videos I have watched this year.

DICE 2010: "Design Outside the Box" Presentation Videos - G4tv.com

In it Jesse Schell, a professor at Carnegie Mellon University talks about the emerging economy that is coming from Gaming.

Facebook game companies (Farmville) sell for $350 Million Dollars, WiiFit made $1 Billion Dollars… Seriously?  Yes, Seriously.

So what does that mean should I just start writing Games?  Well you could, but the real take-away for me was that technologies by nature DIVERGE.  There has been so much prediction about convergence over my career one thing I can assure you of, it will never, ever happen, at least not in a free market economy.

This means that I need to be prepared in whatever software I am writing to be able to adapt quickly to both changing needs and changing systems.

Technologies such as MEF – “Managed Extensibility Framework” and Reactive Extensions for .Net (Rx) are going to become ESSENTIAL tools in your toolbox.

Why MEF?  because we are going to need to extend apps without completely rewriting things, share lots of components between apps and add new functionality on the fly… MEF not only enables this, it makes it so you can create a completely composable application built from a bunch of independent parts.  3rd parties can use our Contracts and add functionality too.  This is going to be extremely important in the very near future.  We’ve been headed down this path for a long time, composability is what makes it now even more compelling.

Why Reactive?  Because our software is really going to really start living in a push based ecosystem… grab data from a source somewhere out in the ether and do something with it when I get it.  Rx makes coding this much easier than trying to manage it with a pull based Enumerable mentality.

Pull based stuff is great when you have a few components and know when you need to grab data, but what if you don’t know, or don’t care when and if you receive it… Reactive makes this style easier to manage.

If you aren’t building all your new Applications as Composable Components, then you are shooting yourself in the foot.  It doesn’t matter if they are Web Apps, Silverlight or WPF, they should all still be components so you can manage, test, extend or replace them much easier than trying to complete a working system that is even loosley coupled with IoC.

Composability is key.  “Composable Parts export services that other Composable Parts need, and import services from other Composable Parts… Composable Parts are either added to the container explicitly or created through the use of catalogs.”

This lets us create a shell and just start adding things to it, some will be complex things, what does the thing do? The shell doesn’t care, it just creates one and makes it available.  How does it interact with another thing?  Reactive makes this easier to manage through some Contracts coupled with MEF to compose them.

The Video above talks mostly about how gaming is going to pervade many things; essentially what it is really saying is that all these little composable parts are going to be interacting with each other.  Your apps need to be prepared for that, How?  MEF and Rx!

Learn them, Love them, Give feedback, because you are probably going to be using them constantly (or wish you had) from now on.

I am starting a series of posts based on exactly this, how is this new architecture going to work?  How do I build Real-world Apps with it?  Precisely what I am going to be covering as I go from the ground up to put the puzzle pieces together.

After Installing VS2010 RC I had a strange crash occurring whenever I hovered over an Intellisense suggestion.

The culprit is a known issue with some devices using UIAutomation and is documented here.

My solution did not appear in any of the suggestions.

I have a Wacom Bamboo Fun device for doing Multi-touch development on my desktop machine.  While this bug has nothing to do with the device itself (it is completely a Visual Studio 2010 issue which is already corrected for RTM) it does require you to disable the device:

Open Control Panel / Hardware and Sound / Devices and disable the Wacom Mouse Monitor

Disabling the Driver alone did not work for me.

Open Controls Panel / Administrative Tools / Local Services

I didn’t want to uninstall unless I absolutely had to, so I also Stopped the WTouch Service:

With both these Disabled the solution works properly without uninstalling the driver, I want to be able to still use the device when I am not actively developing (which is almost never recently…)

Uninstalling the Driver and associated software is another option.

There should be a patch/Hotfix coming soon since they already know what the problem is and have it fixed.

I was working on a conversion of a Visitor Pattern and this was not giving me much information to go on to resolve the problem:

See:  http://msdn.microsoft.com/en-us/library/bb534318.aspx

.NET Framework Class Library

Expression.New Method(ConstructorInfo, IEnumerable(Expression), MemberInfo[])

Creates a NewExpression that represents calling the specified constructor with the specified arguments. The members that access the constructor initialized fields are specified as an array.

The usage sample for VB:

returnValue = Expression.New(constructor, arguments, members)

This will not Compile, you will get the following error:
    Constructor call is valid only as the first statement in an instance constructor.

This is an erroneous error since that is not actually what we are trying to do.  We are trying to call a method that just happens to be the same name as a Constructor in VB.

To work around this, surround the New keyword with brackets:

returnValue = Expression.[New](constructor, arguments, members)

You will not be prompted to do this, nor will intellisense change it for you, it can be rather frustrating when you are not sure what the problem is. 
You will find this also happens when trying to use System.Enum at various times, this one however is not consistent it depends on what namespaces you have Imported.
This same problem occurs in different variations for other Methods or Properties with names that are special keywords, surrounding them with brackets is the solution.

Guess what I’m going to be diving into in the coming months :-)

What is MonoTouch?

MonoTouch is the Mono edition for Apple's iPhone and Apple's iPod Touch devices.  MonoTouch allows developers to create C# and .NET based applications that run on the iPhone and can take advantage of the iPhone APIs as well as reusing both code and libraries that have been built for .NET as well as existing skills.

MonoTouch from Novell

I think it's critical for us all to start rethinking how we build interfaces.

One thing about Ford/Microsoft Sync is that it is entirely designed to expect the user to be doing something other than thinking about how to make it do what you want (like driving)

With the coming onslaught of Win7, mobile devices, better voice and pen recognition as well as multitouch we need to stop thinking about mice and keyboards as the sole primary inputs.

Personally I am delighted we are finally able to use these reliably. Microsoft’s voice development team used to be known as the “wreck a nice beach” group… Today, the Speech SDK is very usable.  My primary input for Twitter is transferring to voice from my iPhone.  I never really thought the iPhone was a critical device until I actually bought one… I use it 100x more than my iPod Touch.  Gee, there’s no mouse on that thing, the interface suddenly needs to be different.  Right-Click? what’s that?

We have a lot to learn about input and information overload.  The web is really starting to suck badly for many people such as my mother.

She was trying to upload some pictures to share with the family and couldn't figure out how to coordinate between Explorer, Picasa, EasyShare and Gallery that all the different people were using, nor should she have to.  All this stuff is FAR too overwhelming for the non-Geek. Try explaining why an Album in Picasa isn't the same as a Folder in Explorer and one program puts things in Public Pictures and another in My Pictures.  Which click, right or left… single, double or triple click… this is madness.

We might also suggest Search but all the pictures are intelligently named things like img10472.jpg, etc. So what does she search for?  Teaching her to rename everything when importing is not so fun either.  Can she get Geo-Location on the camera? Maybe, but also limited use in searching. I have thousands of picture and have no idea who is in most of them.  Why can’t my Photo Browser recognize when I say “That’s Jake and Kelly on a Horseback Ride in Cave Creek”? Then promptly update the Metadata of photo its displaying?  It already has the date, so now a search might be worth something.

So what do we as designers and developers do? Alienate all non technically degreed users?  I have a friend from high-school that subscribes to my Facebook page, which echoes my Twitter feed. I laugh out loud nearly every time he replies that he has no idea what the heck I am saying… ever, which is frequent.  Computers are supposed to be tools, not instruments of torture or mass destruction.

I think it is up to us geeks to make these things more intelligent so not only is it easier for the user to shuffle stuff around from 3 or 4 cameras, notebooks, phones, music players, game devices, cars, TVs, etc. but at the same time make it so a developer of this stuff doesn’t lose their mind trying to accommodate the ever increasing demands of users who have no idea how to use any of this software nor any time to learn the intricacies of the interfaces.

One thing is for sure. The days of the dedicated PC are over. Sharing is important. No one cares how organized my files are or what they are named but I still need to find things. We need to be able to move important items from one place to another without hassle, often someplace other people have access to them who don’t care about your organizational skills.

I don't always type emails from a desktop computer any more. Sometimes it is my phone, sometimes it's my notebook. Can I easily sync my email?  Not really, Contacts... Harder... Calendar, next to impossible. In a semi-connected, mobile world mixed with different OSes, Consumer Electronics and PCs we have a lot to think about before we sit down and start hacking a program together for even the simplest tasks these days.

This was originally a post written on my iPhone in reply to thoughts about developing for things like Microsoft Sync in a language not supported because apparently Microsoft and Ford don’t think anyone is capable of writing apps for it.  I thought the idea deserved to be expanded just a little and blogged for more visibility because it is a driving force in what my company, Digital Dreamshop does.  We try to make interfaces for everyone, not just people who are used to using computers or can tweak settings here and there to make the software “work for them”.

More and more we are finding that people using our software know less and less about how a computer works and strive to accommodate that.  They are using our software to accomplish a task, if it’s overwhelming, “your software sucks”.  If you get in the users way, they hate your app.  I recommend reading http://www.whysoftwaresucks.com/ as well as David Platt’s book if you are not a developer.  Another good read is http://www.sensible.com/ even though the site truly sucks in appearance :-)  I recommend these for the general ideas they represent, not necessarily their solutions.

We will never live in a one philosophy world, especially when it comes to software, OSes and Interfaces, get over it and figure out how to make it easier to get things in and out of your application and how to treat the User as the one controlling the reason you have a job.

If your boss is telling you that their way is the only way and the users don’t know, quit and get a job with someone who gives a damn about User Experience. Old mentalities of forcing methodologies on users and putting them in a box is going to die fast. 

Our Applications need to talk to the outside world, both in terms of the Interface and the Data.  One thing is for sure, the number of devices, programs, and the data they contain will only grow with time.  How will your Applications interact in that world?  Do you even have a plan?

Jeff makes several Great points here about Regions,  Comments, Threading, Refactoring and Naming conventions.

We don’t always practice them all here, but strive to do better.  Most of our Code Generation templates do output code that is very descriptive and readable even if we don’t expect people to read the code, the Philosophy is along the lines of “but what if we need to during debugging or something…”  Having clear and concise coding guidelines makes that task much easier.  Describing what something is supposed to accomplish in the comments has been an essential practice for a long time, code no longer describes itself when you are not writing monolithic apps, even then it was a sure challenge just to find things.

Great custom control development is a skill that takes more than time and experience to perfect. It’s also not a widely documented practice. When it comes to Silverlight controls, there are similarities and differences from WPF custom control development, too – so that chapter on controls in your favorite WPF book often is not directly applicable.

…

I do admit that there’s a lot of flexibility in control development, so I’ll be basing a lot of my tips on both official and unofficial practices on the Silverlight Toolkit team. And I understand if you don’t agree with everything I have to say. But I do hope this information will be useful!

Jeff Wilcox – Custom Control Development: Simple code guidelines

My Technobabble

Lately there is a lot of momentum and interesting conversation around Model-View-View-Model. There’s several good resources out there that discuss the basics of the pattern, who the actors are that are involved and what role the play. I’ll let those speak for themselves, including John Gossman’s great post here, Martin Fowler’s post on the more general PresentationModel pattern and more recently Josh Smith’s MSDN article, Rob Eisenberg’s new series, and Ward Bell’s posts which touch on some of the deeper complexities involved.

In many of these discussions (not including the posts I referred to) it seems like one aspect of ViewModel get’s lost, which is “Why use it in the first place?” This leads to a lot of debate around details of implementation including one item in particular which is whether or not code in the code-behind is an anti-pattern. Building off of the stage Phil set in his great LOD post, I’ll say ViewModel is not a code-counting exercise.

These are all GREAT points. 

Something else Glenn covers is Commands:

The last thing I want to touch on relates to invoking commands, and usage of command parameters through element binding, vs using bound properties on the ViewModel. The user selects an item in the Order list, and double clicks. Do we a) Use element binding and have clicking on the “Open Order” button invoke the OpenOrder command passing in the currently selected order as a parameter, or b) Set the orders list selected item to bind to a SelectedOrder ViewModel property and then have a parameterless OpenOrder command which uses the SelectedOrder order property on the VM itself.

I agree with his assessment that this stuff should use method B.

My reasoning is sort of the same.  Element Binding is nice, but it does make the Designer responsible for something that should be in a Unit Test and this I feel is a no-no.

Element binding is useful for scaling with a slider, but NOT for changing display based on Persisted Data; that relationship belongs in the ViewModel.

Views can have code as long as they exclusively touch Display Only elements, an example would be Style Changes, if you need to invoke some code to load a resource, then that should be in the ViewModel, but to invoke a change based on binding, like a trigger, that may be perfectly fine in the View.

While we are still in the beginnings of applying these patterns to Silverlight, I should point out that if we are forced to overcome a “bug” in rendering, keep that in the View, because the ViewModel just gets muddied up if you don’t; especially if you intend to share your ViewModel with WPF.  Most likely the same “bug” would not exist in both UIs.  Then when a refresh is done and the “bug” goes away in Silverlight, you only have to deal with a change in the Silverlight View.

Maintainability is the key here and the reason these patterns exist.  Keep your code where it belongs for maintainability and you a following the pattern correctly.

The August 2009 meeting of the Phoenix Silverlight User Group featured a fabulous demonstration of Prism with Silverlight.

Adam J Wolf presented a great sample of a project he created.

The Silverlight Prism Prezi was also very impressive and Comprehensive (click the link to view it.)

Adam dove into lots of code and walked us through how Prism makes a compelling case for Flexible, Loosely-coupled Silverlight development.

He showed us how a Modular Design can speed development and offer great flexibility for the future of your App.

One particular part of the Architecture I really liked was how he made a Secure Shell, then loaded all the components from independent XAPs.

This allowed his App to start fast and dynamically get the components it needed on first run, then cache those for future use.

Hats off to Adam for delivering a tremendously useful presentation.

Tim Heuer stayed afterward and showed us the new HP TouchSmart tx2z multitouch enabled Tablet.

This got many people thinking about how Touch can be really useful and change the way some UI elements are engineered.

Thank you again to Adam and Tim for making this another great meeting.