Before even getting to the point of writing a document, there are very distinct user experiences (UX). I have my own preferences, but I am very curious what others think.
When somebody decides to create a new Microsoft Word Document in the Windows Live Site on their Skydrive they’re presented with this interface.
Windows Live Skydrive Microsoft Word Document (Click for full size image)
To start typing in the prospective document you much choose your security, enter a document name, and save the document. It assumes that you absolutely want a unique name, will have a document viewable by the entire Internet, and that you have to save it just to start.
In Google Docs though the approach is entirely different. When you create a new Google Document you are presented with the actual document interface as shown.
Google Docs Interface (Click for larger image)
Google Docs assumes that you want to immediately start typing your word processor document. It also assumes you may not know what you want to name the file, nor that you even need to actually save it, until you of course start typing. At that time the document starts to automatically save. It also assumes that this is your document and you don’t want the entire world to be able to view the document.
So I’m left with questions:
Which interface do people really prefer?
Do people prefer to start typing immediately or filling out the three pieces of information like the MS Word Doc requires?
One appears to allow for immediate productivity for the document creator vs. the other one. Is that just my observation or do others see it that way also?
Please let me know your two cents, I’m truly curious about which UX works out better for you.
Microsoft announced today that they’ll be supporting an effort to get Node.js working on Windows. Mary Foley picked it up quick, but also so did Node creator Ryan Dhal. This, being the explosion of support for Node.js, is excellent news. This further enables JavaScript for the whole stack, on any operating system stack. Getting a good solid, stable, and supported version on Windows will enable some serious performance on that platform. Up until the release of the support, Node.js is primarily limited to Windows via software called CYGWIN, which emulates (or runs on?) Windows and simulates a Unix/Linux Environment.
I’ll have more information regarding Node.js, Node Package Manager, and the whole suite of packages to get started with Node Development over the next couple of days. So stay tuned if you’re interested in getting started!
I’ve been wanting to do a quick write up on the state of cloud apps from my perspective. What’s my perspective? Well I’m keeping up with the SDKs from the big players; AWS and Windows Azure. I’m also working on several cloud applications and providing consulting for some people and companies when approached related to which stack to go with, how to apply their current stacks (such as Ruby on Rails or .NET) in migrating to a cloud service provider. Cloud services, or really more accurately utility computing has my personal and professional interest. Above all, I keep trying to stay informed and know what the best path is for anyone that seeks my advice for moving into hosting & working in the SaaS, PaaS, or IaaS Space. Feel free to contact me in regards to cloud questions: adronhall at the famous gmail dot com. 🙂
Now on to the good tidbits that have been released lately.
These two SDKs are great for customers who want to build on the bare bones X platform. Now whatever language & stack one builds in they are tied to that. Ruby on Rails, .NET, Java, PHP, or whatever. But getting tied to the stack is kind of like breathing air, one has to live with what air they have. You can’t exactly get a refund very easily on that.
The Cloud SDKs though for Azure & AWS provide a certain amount of lock in, in addition to the stack lock in you’re using. One of the easiest ways to prevent this lock in is to use a general deployment method backed by source control on something like Git or Mercurial. So far though, .NET has been left out the cold. There has been almost zero support for pushing .NET via Git or Mercurial into a cloud.
Heroku
Ruby on Rails however has had support for this since… well since the idea popped into the minds of the people at Heroku, EngineYard, and the other companies that are pushing this absolutely amazing and powerful technology pairing.
Engine Yard
Again, for .NET, the problem is it has been left in the dust. Smoked. It has left a lot of .NET Developers moving to Ruby on Rails (which isn’t new, this is just one more thing that has pulled more developers away from the .NET stack).
Well, that’s changed a bit. FINALLY someone has gotten the Git + .NET Pairing in the Cloud put together! FINALLY you can get a cloud application running in a minute or two, instead of the absolutely inane amount of time it takes on Windows Azure (15+ minutes most of the time). So who has done something about this?
AppHarbor is the first fully deployable solution for the cloud that allows Git + .NET to get going FAST! I don’t work for these guys at all, so don’t think I’m shilling for them. I’m just THAT happy that .NET has been pulled out of the dust bins and the community has this option. I am flippin’ stoked matter of fact.
Currently, because of pricing and ease of deployment, I’ve been solely using AWS. I can have a .NET MVC app running in AWS in about 5-10 minutes. Between that speed of setup and the pricing, I pay 2/3 as much as Azure would be and can deploy much fast with a completely traditional .NET deployment. No special project type needed, no extra configs, just a straight deployment with full control over the server (i.e. I can RDP in with no problem). Anyway, the list of reasons I went with AWS over Azure really deserve an entire blog entry unto themselves.
AppHarbor
With AppHarbor though I can step into the realm of doing exactly the same thing a Ruby on Rails Developer would do with Heroku or EngineYard. Fully PaaS Capable with the scalability and features without needing to port or migrate to an entirely new stack! I’ll probably keep a number of things running on AWS (such as the pending WordPress Websites I am about to push up to AWS), but will absolutely be starting up some applications to run in AppHarbor.
If you’re a .NET Developer and you’ve been wanting, looking for, and frustrated that the .NET Community didn’t have a Git + Cloud Deployment option for .NET, wait no longer. Give AppHarbor a look ASAP!
Microsoft announced today that they’ll be supporting an effort to get Node.js working on Windows. 
You must be logged in to post a comment.