SharpEdge Software Blog

Would Be Better.com: Lessons learned building a site with a social component

I had no delusions of becoming as popular as Twitter or Facebook with Would Be Better, at least not right off the bat ;) so it came as no surprise when almost nobody signed up for the site.

Release early and release often, you hear them say. Or, a favourite one of mine, if you’re not ashamed of version 1.0, you didn’t release early enough. And just in case you think I’m being sarcastic or that this is going to be a rant, you’re wrong: I couldn’t agree more with both statements.

Anyway, so I put Would Be Better up quite early and have been adding features here and there more or less ever since, but how did I drive traffic to it?

Come to me

I decided to give StumbleUpon campaigns a try, even though I know not all traffic has the same quality level. So it was in any case a conscious choice: let them come en masse, and some might stick, but even counting on the power of sheer numbers not many visitors created an account.

Which isn’t that surprising at all really: Most users, including you and me dear reader, are fed up with creating new accounts for everything, some of which require you to give irrelevant personal details to sign up; most of which require you to provide a valid email address.

So the obvious solution is, let them use an account they already have to sign up for Would Be Better.

OpenID to the rescue

Most people out there already have an OpenID-enabled account somewhere, even if they don’t know it. Gmail, Windows Live, Yahoo Mail, Facebook, Twitter, LinkedIn are some of the platforms that act as OpenID providers, and there are many more.

So, as you may remember, the next step was a no-brainer, and armed with an OpenID-enabled sign up process I re-enabled the StumbleUpon campaign and waited for the magic to happen. Until, all of a sudden: Nothing.

Nothing worth mentioning in any case. There was some improvement in the conversion rate, and at least almost all new users had acknowledged my effort by using the OpenID login, but it’s not like potential users were piling up to sign up.

Most importantly, to this day 95% of the users are one-time posters, never to return again. The other 5% consists of me and people I know well.

What do people actually want?

So what does Would Be Better lack that prevents users from coming back? Well, for one, after taking a deep, hard look at Would Be Better I realised that for a social site there wasn’t much social component to speak of…

Hah! So that’s why I don’t have whole herds of believers knocking at the Would Be Better doors! People are social beings! They want to interact with each other!
Piece of cake, right? Wrong.

I followed the next logical step: enabling comments on suggestions. If people can let their thoughts loose on other people’s suggestions they’ll sure come back to check if there are any replies to their comments or event comments on their own suggestions? Well you’d think so but that didn’t have the desired effect either, and I think I know why.

Your name rings a bell but…

People might be social, but they are above all, lazy, busy or absent minded or all three and need to be constantly reminded of their appointments, to-do lists, and, of course, that your app exists.
Even Facebook, a central part of so many people’s daily lives, does a terrific job of reminding you every now and again that it’s there!

And that’s where we’re at with Would Be Better. Would Be Better lets you post suggestions, lets other users comment on your suggestions and it even let’s you mark a suggestion as “Is Better”, allowing you to explain how or why. What Would Be Better does not do, is notify you, dear user, of any activity or news around things you have posted.
What we were arrogantly expecting of our users, is that they’d make some free time in their busy online agenda, not only to come pay us a visit, but to remember on their own to come and take a look.

If that’s not being self absorbed I don’t know what is.

Hi! It’s me again!

So we’ve seen the light. Again. We’re currently busy bees working on an alert system for Would Be Better that’ll let you know right from the moment you log in whether there’s anything worth checking regarding your suggestions and comments. The same alert system will take care to send you an email whenever there’s new activity that might concern you.

That’s right, we’re becoming less arrogant by becoming annoying.

But don’t worry, needless to say there’s account settings that allow turning off email notifications and newsletters.

Wait, what newsletter?

Exactly. That’s saddest part: there’s been in Would Be Better a mechanism to remind the users of our existence all along! The tricky thing I’ve discovered about newsletters though, is that it’s all very good an well to have a nice system to compose and send newsletters to your users, but you have to actually use it for it to be any good…

So what’s the lesson?

Well, I’ve been spreading all the “lessons learned” all along this post really, but the most important point is probably that it’s all a work in progress, and that assumptions and theories about what might work and what won’t are all very well, but you have to try it:

Let your idea loose “in the wild”
See if it works
Adapt
Rinse and repeat

Do you have (dis)similar experiences? Care to Share them? Let me know!

Usability round-up

Those of you who have bothered reading the landing page might have noted several references to user friendliness, usability and so forth. I thought it’s time to put our money where our mouth is and talk a little bit about that.

To start off nice and easy, this post will just be a round-up of interesting links concerning either Usability or User Friendly design, or both.

Books

Most of those are quite know already so don’t expect to be blown away. Still, might be nice to have them all in a row. None of these are affiliate links, by the way:

Don’t Make Me Think (by Steve Krug)
Rocket Surgery Made Easy: The Do-it-yourself Guide to Finding and Fixing Usability Problems (by Steve Krug)
The Inmates Are Running The Asylum (by Alan Cooper)
About Face 3: Essentials of Interaction Design (by Alan Cooper)
The Design of Everyday Things (by Don Norman)

That’ll be it for now. If you have any other valuable links, by all means, Let me know and I’ll be sure to add them to the list.

Simple Time Picker model binder for ASP.NET MVC 3, and how to save it to SQL CE 4 using EF 4.1

There’s plenty of DatePickers out there, like, for instance, the ubiquitous jQuery DatePicker, but how about Time pickers?
Well if you’re looking for a fancy, flashy, drop-dead-gorgeous Time picker control… this post isn’t for you. What this post will teach you, dear reader, is how to simply and effectively use two Dropdowns to to model bind hours and minutes to a TimeSpan. This will be the jaw-dropping end result:

The Model and our constraints

We’ll set up a very simple model because in this case all I care about is saving the time. Let’s say we have an Appointment class, with only an ID, a name and a time:

using System;
using System.ComponentModel.DataAnnotations;

public class Appointment
{
    public int ID { get; set; }
    
    public string Name { get; set; }
    
    public long Ticks { get; set; }
    
    [NotMapped]
    public TimeSpan Time
    {
        get { return TimeSpan.FromTicks(Ticks); }
        set { Ticks = value.Ticks; }
    }
}

There’s several things going on here. As you can see, I’ve split the representation of time into two properties. The Time property itself is calculated from the Ticks property (an inherent property of the TimeSpan struct). It is also marked with the NotMappedAttribute, which will instruct Entity Framework to not map this property to the database. Instead, we’ll save the Ticks property to the database and reconstruct the TimeSpan from the ticks every time.

Why make it so hard? It appears that SQL Server Compact 4 does not declare any datatype to represent a TimeSpan. Hence our workaround. To be honest, I haven’t tried this in SQL Server (the Big Boy edition, I mean), so it could be that you can get away mapping the TimeSpan directly. This will definitely work on all versions though.

The EditorTemplate

Next we’ll define what the standard look of our “time picker” will be. Even though we’re saving the Ticks property to the database we’ll use the Time property for display. The type of the property is TimeSpan so that’s how we’ll have to name our EditorTemplate. Create a new folder in the Shared views folder of your application, call it “EditorTemplates” and add a partial view called TimeSpan.cshtml (or TimeSpan.ascx if you’re using the WebFormsViewEngine instead of Razor). You folder structure should look like this:

This is what TimeSpan.cshtml will look like in order to render the 2 Dropdowns depicted above:

@model TimeSpan

@Html.DropDownList("", Enumerable.Range(0, 24)
    .Select(i => new SelectListItem { Value = i.ToString(), 
    Text = i.ToString(), Selected = Model.Hours == i }))&nbsp;:

@Html.DropDownList("", Enumerable.Range(0, 60)
    .Select(i => new SelectListItem { Value = i.ToString(), 
    Text = i.ToString(), Selected = Model.Minutes == i }))

In a nutshell, we make TimeSpan.cshtml a partial view typed to TimeSpan, because that is the type of the Time property, then we “generate” 2 DropDownLists, the first one with the values 0 to 23 (24 is the upper bound and is not included) for the hours and 0 to 59 for the minutes.

Calling the template

In order to tell ASP.NET MVC to render our Time property using the TimeSpan Editor template we just need to use the EditorFor Html helper. So suppose we have a view called Add in an AppointmentController:

@model Appointment

@using(Html.BeginForm()) {
        
    // more fields here...    
    @Html.EditorFor(model => model.Time)

    <input type="submit" value="Hit me!" />
}

That’s it really. ASP.NET MVC will take care of the dirty work of trying to find an Editor Template that matches the type of the Time property. Now we just need to bind the value of the two Dropdowns into a single TimeSpan.

Black magic

Well, not really of course; simple model binding at work. Create a new class and call it, for instance, TimeBinder. Our editor template will provide us with 2 values once we post the form, one for each Dropdown. The work of TimeBinder will be to get the 2 values and return a TimeSpan:

public class TimeBinder : IModelBinder
{
    public object BindModel(ControllerContext controllerContext, 
        ModelBindingContext bindingContext)
    {
        // Ensure there's incomming data
        var key = bindingContext.ModelName;
        var valueProviderResult = bindingContext.ValueProvider
            .GetValue(key);

        if (valueProviderResult == null || 
            string.IsNullOrEmpty(valueProviderResult
                .AttemptedValue))
        {
            return null;
        }

        // Preserve it in case we need to redisplay the form
        bindingContext.ModelState
            .SetModelValue(key, valueProviderResult);

        // Parse
        var hours = ((string[])valueProviderResult.RawValue)[0];
        var minutes = ((string[])valueProviderResult.RawValue)[1];

        // A TimeSpan represents the time elapsed since midnight
        var time = new TimeSpan(Convert.ToInt32(hours), 
            Convert.ToInt32(minutes), 0);

        return time;
    }
}

Final setup

Now that we have a binder in place we need to instruct the application to use it. Add the following line to the Global.asax.cs file, in the Application_Start method:

protected void Application_Start()
{
    ModelBinders.Binders.Add(typeof(TimeSpan), new TimeBinder());

    // route registration code here
}

DropDownLists? Meh.

I hear you saying, isn’t it more convenient to just type the hours and minutes yourself? Why use tedious Dropdowns?

You’re probably right. The beauty of what we’ve just done is that we now only need to change the TimeSpan.cshtml partial view to display two TextBoxes instead of DropDownLists and it will just work!

Don’t believe me? Here’s the new TimeSpan.cshtml:

@model TimeSpan

@Html.TextBox("", Model.Hours)&nbsp;:
@Html.TextBox("", Model.Minutes)

ASP.NET MVC will give the TextBoxes the same name it gave the Dropdowns, which means our TimeBinder will still be able to fetch the values from the ValueProvider and parse them. Quite an example of loose-coupling your presentation layer from your business layer if you ask me! :)

Of course, without the Dropdown limiting the range of values a user may input you’d better restrict those TextBoxes to numerical values only, otherwise you’re up for some fancy runtime errors ;)

Any questions? Let me know!

Using dynamic to unit test an Action Method that returns JsonResult with MVC 3 and C# 4

We’ve all been there, haven’t we? We have an action method that we call through Ajax.ActionLink, Ajax.BeginForm or even with jQuery.ajax, and returning a JsonResult is what makes the most sense. But whatever you pass to a JsonResult only gets exposed through the JsonResult.Data property which, unfortunately, is of type object.

JsonResult is meant to be serialized into a string with Json notation so it doesn’t matter that Data is of type object, but, how do you access the properties inside the Data object when you want to unit test your view?

The setup

We need an action in a controller that returns a JsonResult; it doesn’t matter how it gets called from the view or what we’d do with the result, so let’s keep it simple:

public ActionResult DoSomething()
{
    var ok = Act();

    var message = ok? "All done!" : "Oops!";

    return Json(new { Message = message });
}

And the unit test:

[TestClass]
public class Test
{
    [TestMethod]
    public void DoSomething_Does_Something()
    {
        // Arrange
        var controller = TestFakes.CreateController();
        
        // Act
        var json = controller.DoSomething() as JsonResult;

        // Assert
        Assert.IsNotNull(json.Data.Message); // --> FAIL!
    }
}

The test fails not because Message is null, but because json.Data is of type System.Object and System.Object doesn’t have a Message property, obviously.

What now? Well, I give it away in the title of this post so it’s hardly a cliff-hanger, is it?

Dynamic to the rescue

Thanks to the magic of statically typing as dynamic in c# 4 this should be a piece of cake. Let’s modify the test method:

[TestClass]
public class Test
{
    [TestMethod]
    public void DoSomething_Does_Something()
    {
        // Arrange
        var controller = TestFakes.CreateController();
        
        // Act
        var json = controller.DoSomething() as JsonResult;
        
        // Dynamic magic: just assign the Data property
        // to a variable of type dynamic!
        dynamic data = json.Data;
        
        // And get our message out of it.
        string msg = data.Message;

        // Assert
        Assert.AreEqual("All done!", msg); // --> OK!
    }
}

It’s that simple: just assign the Data object to a variable of type dynamic, then access the Message property. Note that I cannot declare the variable msg as var. That’s because data.Message is a dynamic expression that will be resolved at run time, so the compiler wouldn’t know what to substitute var for at compile time.

Er, it doesn’t work

If you actually run this test, you’ll get an "object does not contain a definition for Message" error. Oops. Didn’t we convert json.Data to a dynamic object? Well, yes but…

Anonymous types are internal

JsonResult returns an anonymous object and these are, by default, internal, so they need to be made visible to the tests project.

The solution

This is, fortunately, very very simple to solve.

Assuming you have your test classes in an assembly called MyProject.Tests, find the file AssemblyInfo.cs in the Properties folder in your MVC project. Open AssemblyInfo.cs and add the following line to the end of the file:

[assembly: InternalsVisibleTo("MyProject.Tests")]

Do you know of a better way? Any questions? Let me know!

Mocking a ControllerContext with authenticated user with Moq for ASP.NET MVC (3)

Whenever you are writing unit tests or BDD-style specs for your ASP.NET MVC controllers (you are, right?) there will come a moment when you actually need to simulate that a user is authenticated to your site.

Even if you’re familiar with mocking, letting the controller think someone has logged in to your site might not be straight forward. Fear no more.

Mocking

I’ll be using Moq as my mocking framework. I’ve tried RhinoMocks in the pas but I find it personally to verbose, but what I’ll show you here should be very easily translated to RhinoMocks or any other ol’ mocking framework out there.

Failing test

So let’s say the controller looks like this:

public class AdminController : Controller
{
    [Authorize]
    public ActionResult ViewProfile()
    {
        // pass the authorized user name to the view
        var username = User.Identity.Name;

        return View(username);
    }
}

If we want to test the ViewProfile action, the unit test will fail:

[Subject("AdminController")]
public class When_the_profile_page_is_requested
{
    static AdminController controller;
    static string username;

    Establish context = () =>
    {
        controller = new AdminController();
        username = "Sergi";
    }

    Because of = () => result = controller.ViewProfile();

    It should_know_the_username = () =>
        result.Model<string>().ShouldEqual("Sergi");
}

I’m using MSpec with James Broome’s Machine.Specifications.MVC extensions for the specs (tests) here. If you’re not familiar with MSpec, don’t panic, just know that the Establish, Because and It correspond to Arrange, Act and Assert of traditional TDD.

But this spec will obviously fail because we’ve marked our action with the Authorize attribute and even if we hadn’t we’re trying to get the logged in username through the controller’s User property, which will be null when no user has logged in.

Getting it to pass

So how do we set our controller up?

[Subject("AdminController")]
public class When_the_profile_page_is_requested
{
    static AdminController controller;

    Establish context = () =>
    {
        controller = new AdminController();

        var controllerContext = new Mock<ControllerContext>();

        // Just fake the name of the user we want to
        // "authenticate"
        controllerContext.SetupGet(x => 
            x.HttpContext.User.Identity.Name).Returns("Sergi");

        // And tell the controllerContext that, sure,
        // we've logged in allright...
        controllerContext.SetupGet(x => 
            x.HttpContext.User.Identity.IsAuthenticated)
            .Returns(true);

        controllerContext.SetupGet(x => 
            x.HttpContext.Request.IsAuthenticated)
            .Returns(true);

        // now that we've set up the controllerContext
        // pass it to the controller
        controller.ControllerContext = controllerContext.Object;
        
        // As a bonus, we initialize the Url helper
        // property of the controller as well
        var context = 
            new Mock<HttpContextBase>(MockBehavior.Strict);

        controller.Url = 
            new UrlHelper(new RequestContext(context.Object, 
            new RouteData()), new RouteCollection());
    }

    Because of = () => result = controller.ViewProfile();

    It should_know_the_username = () =>
        result.Model<string>().ShouldEqual("Sergi");
}

A controller exposes the current HttpContext through the ControllerContext property. Here we tell Moq to set up only certain properties of ControllerContext; only the ones we’re going to use.

That’s what the SetupGet method does.
For instance on line 13 we’re saying: “when someone calls ControllerContext.HttpContext.User.Identity.Name, return the value we’re specifying, “Sergi” in this case”.

The User property on the Controller class actually exposes this same ControllerContext.HttpContext.User object.

When all is set up we need to pass the ControllerContext to the Controller; that’s what happens on line 28. Why are we actually calling controllerContext.Object? Well, if you look where we initialize the controllerContext variable we really create a Moq.Mock<T> object. Mock<T> exposes the real object T through the Object property, which is exactly what out controller needs.

I hope this helps. Any questions? Let me know!

Dealing with javascript or JSON results after an AJAX call with Ajax.ActionLink, unobtrusive AJAX and MVC 3

I’ve recently updated an MVC 3 project to use unobtrusive ajax. If you create a new ASP.NET MVC 3 project unobtrusive ajax will be enabled by default, but this was a project I had once migrated from MVC 2. Instead of physically adding the unobtrusive ajax JavaScript file to my solution I got it from the Microsoft Ajax CDN.

The unobtrusive ajax libraries not only leave your html cleaner by using the HTML 5 compatible “data-” attribute, but return a much clearer set of results objects from the controller.

The latter was, for me, a great relief, because I always ended up taking care of responses to ajax calls in several different ways within one application. Do I return strings from the controller action or do I go with Json? Or should I always return a HttpStatusCodeResult?

I’ve finally found a pattern, for lack of a better word, that I find clean, clear and consistent. Here’s how.

Calling the controller

Imagine we want to make an ajax call to a controller to, say, change the status of an order. In our view we simply do:

@Ajax.ActionLink("Set to pending", "setstatus", "order", 
    new { id = Model.ID, status = 0 }, new AjaxOptions 
        { OnFailure = "Error", OnSuccess = "StatusChanged", 
            HttpMethod = "POST" })

Two things to notice in the AjaxOptions object:

I explicitly set the HttpMethod to POST. We will be returning a Json object from the controller and the unobtrusive ajax library “encourages” us to avoid going to the server with a GET request for security reasons. You’ll know you have this problem because an exception will be thrown saying “This request has been blocked because sensitive information could be disclosed to third party web sites when this is used in a GET request. To allow GET requests, set JsonRequestBehavior to AllowGet.”
I’ve defined two callback methods, one for error and another for success. These methods will be passed a default set of arguments by the unobtrusive ajax library which we will be able to use from our action method to return the status of the operation and any meaningful messages we deem necessary. These are the method signatures:

function Error(response, status, error) {
}

function StatusChanged(response, status, data) {
}

Action

We want our action to give a meaningful error message when things go wrong, and to return for instance the id and new status of the order if everything goes OK.

[HttpPost]
public ActionResult SetStatus(int id, int status)
{
    try
    {
       // Code to update the order status here

        return Json(new
        {
            ID = id, 
            NewStatus = order.StatusDescription
        });
    }
    catch
    {
        return new HttpStatusCodeResult(418, 
            "Couldn't change the status of the order");
    }
}

Notice how we’ve marked our action to accept HttpPost request only? This is of course because we specified POST as the HttpMethod in our ActionLink to solve JsonReuqestBehavior problem mentioned above. Another solution is to ignore the Http verbs and methods altogether and add JsonRequestBehavior .AllowGet as second parameter of the Json result.

Dealing with the results

Imagine we’ve just changed the status successfully; our action method returns a Json result containing an anonymous type with two properties, ID and NewStatus. We can define these with whatever name we like, or even create a property that is itself an anonymous type. It will all be serialized to Json by ASP.NET MVC. How do we use these on the view? Quite easy really:

function StatusChanged(response, status, data) {
    alert("order #:" + response.ID + "has a new status: " 
        + response.NewStatus);
}

Of course, you’d want to do something a tad more meaningful with your results, but the essence of it is this: The properties you defined in your anonymous type are directly available through the response parameter. Had you defined a property that was itself an anonymous type, named for instance Extras, with other properties in it, you’d simply do response.Extras.WhateverProperty.

And if things go south?

As you can see we have a nice try..catch in our action. When an exception is thrown or there’s an error we want to signal we need make it known in the response. That basically means returning a status code other than 200 (“OK”). Here I’m returning the Http Status Code 418: “I’m a teapot” :þ I promise it is a valid http status code; if you don’t believe me, check Wikipedia!

Anyway, when returning a status code other than 200 our Error function will be called. How doe we deal with the error message? As easy as before:

function Error(response, status, error) {
    alert("Oops! " + response.statusText);
}

So there you have it. Do you know of a better/different way? Let me know!

How to add OpenID authentication to your ASP.NET MVC 3 site using Janrain Engage

Well, I finally took the time to implement OpenID/Social network log-in functionality to Would Be Better and although I had anticipated a much more troublesome process, it wasn’t entirely clear how I had to proceed on several of the steps either. I’d like to share my experiences with you.

Why.

After reading Rob Conery’s horror story about OpenID support for Tekpub, whay on earth did I decide to go ahead with implementing it for Would Be Better? Well, I figured that people would not quite enjoy the idea of having to create yet another account, with it’s corresponding username and password just to be able to use my puny site. At this point I have to remove all possible entry barriers as it is hard enough getting potential users to sign up, so I assumed that allowing people to sign up/in with their Facebook, Windows Live or Gmail account might help things along.

How.

I’m sure there are various ways to allow your users to sign in to your site with openID but having seen several sites using the Janrain Engage widget, including Tekpub, I thought I’d take a look. It turns out they have a free Basic plan for up to 2500 users, and since the day that Would Be Better actually has 2500 users is for now only a wet dream I went ahead and signed up.

Initial setup

The URL where Janrain Engage will send the authentication response is set up when generating the code for the widget. So, Imagine we have an ASP.NET MVC application call MyMVCApp (-1 for originality, I know), and in there we have an Account controller, and we want the Authenticate action to handle Janrain’s response. This is how our widget generation page looks like right now:

If you follow the instructions on the page and “place the code directly in the page where you’d like widget to appear you’re good to go. Almost.
You’ll have to choose some providers next. Some of them require some rather annoying set up, and it is rather unfortunate that a couple of the most popular providers are among those. Would you wanna implement social network login in your site without actually offering Facebook or Windows Live (Hotmail)? Didn’t think so.

In case you’re wondering, these are the providers we chose for Would Be Better:

Facebook requires you to create a Facebook app, and Janrain requires you to register an application with Windows Live. The latter can be a bit confusing, because you’ll have to provide the Janrain domain (something like https://mymvcapp.rpxnow.com/) instead of your own domain when registering the Windows Live app. This makes it impossible for Windows Live to “verify your app”, but it turns out it’s not necessary for the widget to work properly.

Receiving Data

Finally, what you, in all likelihood, came here for; it’s time to get this baby to talk back to us.

First, get the C# helper class provided by Janrain, called Rpx, and add it to your Visual Studio solution. Now we can create the action method Janrain will talk to: go to your AccountController and add the following action:

public ActionResult Authenticate(string token)
{
    if(!string.IsNullOrEmpty(token))
    {
        var rpx = new Rpx("Insert Janrain API key here", 
            "https://mymvcapp.rpxnow.com/");
        var response = rpx.AuthInfo(token);

        var parser = new RpxResponseParser(response);

        if (parser.Status == RpxReponseStatus.Ok)
        {
            var responseUser = parser.BuildUser();
            return AuthAndRedirect(responseUser);
        }
    }

    ViewBag.Message = "There was a problem signing you in." 
        + "Verify your credentials and try again.";

    return RedirectToAction("create");
}

OK, so what’s going on here? Janrain will post a response to our action including an authentication token. We simply get the token and use it to call the AuthInfo method on the Rpx helper class we got from Janrain, which will return a nicely formatted XmlElement with some information about the user that has just logged in.

And that RpxReponseParser? That’s just a small helper class I put together that uses LINQ to XML to help me parse the xml response and return a User object with the Username, email, openID and display name filled in. If you want, download the RpxReponseParser class, along with the RpxReponseStatus enumeration, but remember you’ll have to create the User class yourself.

Wrapping up

As you might have gathered, this code is, with minor adjustments to post it here, straight from the Would Be Better codebase. So what’s up with the AuthAndRedirect method? Well, at Would Be Better we support both traditional username/password accounts and, recently, openID/social network login account.
Since we added social network login support much later that regular username/password accounts, we actually wanted to enable anyone to be able to login with both types of account because, let’s face it, one-click login with MyOpenID is that much easier that typing your username and password. To avoid people with duplicate accounts , once you login with whichever method we try and synch user accounts based (mainly) on e-mail address. That little bit of black magic happens in the AuthAndRedirect method.

I hope this helps.

Moving WouldBeBetter.com away from Windows Azure to traditional hosting

It just happened; the Name Server changes appear to have definitely propagated a couple of minutes ago. Why did I decide to abandon Windows Azure in favour of a traditional hosting for Would Be Better? There is one reason and one reason only: Money.

Hard facts

I’m not going to name any figures, but when looking through the Windows Azure invoices of the last couple of months I realised I could buy a year of traditional hosting including 2 SQL Server database for 2 months worth of Azure!

This was yesterday. That’s right; it took me all of 5 minutes to reach a conclusion, and the only thing that stopped me from migrating the site yesterday already is that the new hosting provider, DiscountASP.Net (the same one hosting this site) needed an hour or 2 to activate the new account.

Being fair

Is Windows Azure a bad platform? No, of course not. It is extremely cool if you ask me and I’m really happy I even took the time to deploy a live app on it. I just think it doesn’t make sense for Would Be Better yet.

And in all fairness, it could be I was doing lots of things wrong and driving the price up unnecessarily, but even reducing the number of databases (3: the main db, one for reporting and one for membership. yeah, yeah, I got carried away. Maybe. :þ), or choosing Extra Small Instances (yes, plural, your need at least to instances to comply with the SLA) would not make up for the hundreds of €’s I’ll save per year by moving to regular hosting.

Ever going back to Azure?

I most definitely hope I have to, but it will only happen when it makes sense. When is that? Well, I think Azure could be a terrific investment if you have, for instance, large hardware needs. It would probably be cheaper to pay for an Azure subscription than buying equivalent hardware (plus you spare yourself some system administration work if you go the Azure route, of course).

If Would Be Better generated huge amounts of traffic, or even better, money, I would have quite definitely stayed on Windows Azure; unfortunately, both things are quite a long way away.

What I’ll miss

Easy. Two things mainly:

1) The incredible Staging/Production environments: That’s right, with every Azure subscription you get the ability to deploy your app to a Staging environment, and when you decide it’s stable, promote it to production with no downtime.

2) Being able to say I’ve got an app hosted on Windows Azure

What I won’t miss

This one’s easy too: Having to wait 10 to 20 minutes (10 to 20!) for a deployment to complete, plus another 5 when you want to promote it to production. This one just drove me insane every time. Imagine what happens when you realize you have a typo in one of your views, or discover a small error in a JavaScript file. Despair, that’s what.

And being fair again, I’ve seen de deployment times go down over the last couple of months so it could just be that somebody is listening…

Would Be Better.com!

The world is full of great, even wonderful things; be it material things, emotions, states of mind... but Everything can be improved. We knew that much, and although we certainly don't know how to improve everything, we know you do. Would Be Better is the place where you suggest how to improve the world; one thing at a time...

That's right, we've launched Would Be Better.com, a micro community site were everybody can make a suggestion on how to improve anything that comes to their minds. Head over there, create an account and start making suggestions.

And while you're there, bask and rejoice in the beauty of the great job the folks at Pixeo have done again at styling the site ; )

Remember, Everything can be improved!

Eternal Debate 2.0: Will the Web replace the Desktop?

It started somewhere in the (very) late ’90, faded away in shame for a while after the Big Burst and, what do you know, it came back with a good dose of supervitamin A(jax) and superminerals provided by the advent of Web 2.0: The Web will make the Desktop a thing of the past. Again.

Now, I know I’m not touching a super hot issue here, but since I only ever read about it from known and sometimes even respected Web 2.0 developers/companies who have, naturally enough, an extremely biased view on the matter, I decided to approach it form the other side: The view of an anonymous Windows and Web developer who disagrees with them.

(Side Note: no Web 2.0 developers, respected or otherwise will be (really) damaged during this rant.)

First off, I don’t even know why such a debate should ever even arise. Twice. I don’t know what it is with the Web and internet, but It seems as though every new thing, every step forward, triggers some as of yet undiscovered testosterone reservoir in tech journalists’ brains that makes them claim that this time hell will really break loose, the end of the world as we know it! And god forbid you miss that train because it is the last one!

“Now departing: Last train out of Stoneageville! Last train! LAST train! Will you just hop in?!?”

What I consistently fail to understand is this need to confront these two environments that for all I know coexist in perfect harmony when left be.
Of course, there are some people out there, by which I mean Google, who would just totally love it if the Desktop, by which I mean Microsoft, would disappear. Mind you, that might be what drove them to revolutionise the web landscape with Google Maps in the first place.

Google Engineer #1: I know! Let’s get rid of Microsoft! And Apple! And Linux! Let’s get Rid Of The Desktop!
Google Engineer #2: Cool! But… er… how are we actually going to develop anything after that?
GE #1: Oh, don’t worry; we’re halfway through Google OS. Beta.
GE #2: What about BeOS?
GE #1: Shut up.

So, for the big one: Will the Web, the thin client, make the thick client a thing of the past? I think that’s a right pile of bullshit. Period.

Don’t get me wrong here, I am, by no means, criticising Web applications. I think there’s a bunch of really cool web apps out there, and many kudos to 37Signals, Gmail, Digg, Litmus (formerly SiteVista), and many others I’m forgetting, I just think people need to get a grip because some things are plain far fetched.

Someone, somewhere, even theorised (or proposed?) that the future operating systems would shrink immensely and become just a platform for running our highly evolved, super capable web browsers. Puh-lease! I think someone should try and leave his web browser alone from time to time.
And why is it always the “web” side of the story that has murderous thoughts about its fatter relative and not the other way around? For all I know the Desktop has always embraced the web; recognised the potential of cooperation. Per la Familgia.

I understand the underlying thought, that the new web applications help build an ever connected world where you data is accessible from anywhere, at any moment, by any Google employee.
But to say we’ll be going back to thin clients, back to terminal era...

- But why would you need anything else if your browser can provide everything you need and your data is stored in servers that are permanently available to you from anywhere?
- And what about confidential data? Stuff you’d rather keep an eye on at all times?
- Well, you could always save it on your Hard Drive, I suppose…
- On what file system?
- Er…

And that might be quite a simplistic rebate, I know, but so is their theory.
What seems obvious to me is that both environments, both worlds complement each other and are meant to share some space in our digital lives. Deal with it.