Tweaking the Default ADFS v2 Web Experience

Designing clean and smart user experiences is a hobby of mine.  Yeah, it’s a little weird, but it’s a good way to change gears for a while when working through a problem.

Given that, I thought I would take a stab at the login pages for ADFS.  I didn’t do anything major, but lets take a look at some before and after shots.

Before

Nothing too complicated here.  It looks like a regular login page.

After

In comparison, not a lot has changed.  I switched the font, moved the textbox labels, fiddled with some border colors, and added a watermark in the username textbox describing the format.

Here is the updated style:

<style>
body
{
    background-color: rgb(255, 255, 255);
    color: #4a4a4a;
    font-family: "Segoe UI" , Arial, Helvetica, Sans-Serif;
    line-height: 1.4em;
    font-size: 12px;
    font-style: normal;
    font-variant: normal;
    font-weight: normal;
    font-size-adjust: none;
    font-stretch: normal;
    margin-top: 20px;
    margin-right: 20px;
    margin-bottom: 20px;
    margin-left: 20px;
    background-repeat: repeat-x;
    background-image: url(../App_Themes/Default/header_background.png);
}
</style>

The next step I’d like to take is add some JavaScript validation.  The default codebase just passes the text to the authentication code, which would eventually throw an exception, inevitably resulting in a little red blob of text saying “the user name or password is incorrect.”  Seems like a waste of a postback if all it’s going to do is remind me that some textbox is empty.

Thinking About how we Display Data

Earlier I had discussed how to bring the data from a database to the Windows Phone 7.  Now I’d like to discuss how we think about displaying that data.  It’s important to know the relationships in the data so we can think about how everything should be structured.  We want to create a simple interface that is smooth and logical.  All data is different and this is by no means the “right” way to do it, but it feels right to me.

This is industry standard stuff, and our data is modeled around it.  Each layer would be a collection of each sub-layer.  So as an example There are multiple tracks per breed, and multiple cards per track.  A Card is a set of races for a specific track.  My best understanding is that we try very hard to stick to one Card per day. 

For this application though we aren’t going to assume anything.

It seems logical to me that we should mimic this structure in the logic, so lets try and shoot for that.  This is not the finished version, but of a mock-up of what we might/should see.

Initial Page:

Once the breed has been selected we move onto selecting the track:

And so on…

In the future I will discuss the breakdown of each page and how the data is actually displayed, plus how we switch between pages.

Getting the Data to the Phone

A few posts back I started talking about what it would take to create a new application for the new Windows Phone 7.  I’m not a fan of learning from trivial applications that don’t touch on the same technologies that I would be using in the real world, so I thought I would build a real application that someone can use.

Since this application uses a well known dataset I kind of get lucky because I already have my database schema, which is in a reasonably well designed way.  My first step is to get it to the Phone, so I will use WCF Data Services and an Entity Model.  I created the model and just imported the necessary tables.  I called this model RaceInfoModel.edmx.  The entities name is RaceInfoEntities  This is ridiculously simple to do.

The following step is to expose the model to the outside world through an XML format in a Data Service.  I created a WCF Data Service and made a few config changes:

using System.Data.Services;
using System.Data.Services.Common;
using System;

namespace RaceInfoDataService
{
    public class RaceInfo : DataService
{ public static void InitializeService(DataServiceConfiguration config) { if (config
== null) throw new ArgumentNullException("config"); config.UseVerboseErrors
= true; config.SetEntitySetAccessRule("*", EntitySetRights.AllRead); //config.SetEntitySetPageSize("*",
25); config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V2;
} } }

This too is reasonably simple.  Since it’s a web service, I can hit it from a web browser and I get a list of available datasets:

This isn’t a complete list of available items, just a subset.

At this point I can package everything up and stick it on a web server.  It could technically be ready for production if you were satisfied with not having any Access Control’s on reading the data.  In this case, lets say for arguments sake that I was able to convince the powers that be that everyone should be able to access it.  There isn’t anything confidential in the data, and we provide the data in other services anyway, so all is well.  Actually, that’s kind of how I would prefer it anyway.  Give me Data or Give me Death!

Now we create the Phone project.  You need to install the latest build of the dev tools, and you can get that here http://developer.windowsphone.com/windows-phone-7/.  Install it.  Then create the project.  You should see:

The next step is to make the Phone application actually able to use the data.  Here it gets tricky.  Or really, here it gets stupid.  (It better he fixed by RTM or else *shakes fist*)

For some reason, the Visual Studio 2010 Phone 7 project type doesn’t allow you to automatically import services.  You have to generate the service class manually.  It’s not that big a deal since my service won’t be changing all that much, but nevertheless it’s still a pain to regenerate it manually every time a change comes down the pipeline.  To generate the necessary class run this at a command prompt:

cd C:\Windows\Microsoft.NET\Framework\v4.0.30319
DataSvcutil.exe
     /uri:http://localhost:60141/RaceInfo.svc/
     /DataServiceCollection
     /Version:2.0
     /out:"PATH.TO.PROJECT\RaceInfoService.cs"

(Formatted to fit my site layout)

Include that file in the project and compile.

UPDATE: My bad, I had already installed the reference, so this won’t compile for most people.  The Windows Phone 7 runtime doesn’t have the System.Data namespace available that we need.  Therefore we need to install them…  They are still in development, so here is the CTP build http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=b251b247-70ca-4887-bab6-dccdec192f8d.

You should now have a compile-able project with service references that looks something like:

We have just connected our phone application to our database!  All told, it took me 10 minutes to do this.  Next up we start playing with the data.

Data as a Service and the Applications that consume it

Over the past few months I have seen quite a few really cool technologies released or announced, and I believe they have a very real potential in many markets.  A lot of companies that exist outside the realm of Software Development, rarely have the opportunity to use such technologies.

Take for instance the company I work for: Woodbine Entertainment Group.  We have a few different businesses, but as a whole our market is Horse Racing.  Our business is not software development.  We don’t always get the chance to play with or use some of the new technologies released to the market.  I thought this would be a perfect opportunity to see what it will take to develop a new product using only new technologies.

Our core customer pretty much wants Race information.  We have proof of this by the mere fact that on our two websites, HorsePlayer Interactive and our main site, we have dedicated applications for viewing Races.  So lets build a third race browser.  Since we already have a way of viewing races from your computer, lets build it on the new Windows Phone 7.

The Phone – The application

This seems fairly straightforward.  We will essentially be building a Silverlight application.  Let’s take a look at what we need to do (in no particular order):

1. Design the interface – Microsoft has loads of guidance on following with the Metro design.  In future posts I will talk about possible designs.
2. Build the interface – XAML and C#.  Gotta love it.
3. Build the Business Logic that drives the views – I would prefer to stay away from this, suffice to say I’m not entirely sure how proprietary this information is
4. Build the Data Layer – Ah, the fun part.  How do you get the data from our internal servers onto the phone?  Easy, OData!

The Data

We have a massive database of all the Races on all the tracks that you can wager on through our systems.  The data updates every few seconds relative to changes from the tracks for things like cancellations or runner odds.  How do we push this data to the outside world for the phone to consume?  We create a WCF Data Service:

1. Create an Entities Model of the Database
2. Create Data Service
3. Add Entity reference to Data Service (See code below)

 
    public class RaceBrowserData : DataService
{ public static void InitializeService(DataServiceConfiguration config) { if (config
== null) throw new ArgumentNullException("config"); config.UseVerboseErrors
= true; config.SetEntitySetAccessRule("*", EntitySetRights.AllRead); //config.SetEntitySetPageSize("*",
25); config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V2;
} } 

That’s actually all there is to it for the data.

The Authentication

The what?  Chances are the business will want to limit application access to only those who have accounts with us.  Especially so if we did something like add in the ability to place a wager on that race.  There are lots of ways to lock this down, but the simplest approach in this instance is to use a Secure Token Service.  I say this because we already have a user store and STS, and duplication of effort is wasted effort.  We create a STS Relying Party (The application that connects to the STS):

1. Go to STS and get Federation Metadata.  It’s an XML document that tells relying parties what you can do with it.  In this case, we want to authenticate and get available Roles.  This is referred to as a Claim.  The role returned is a claim as defined by the STS.  Somewhat inaccurately, we would do this:
   1. App: Hello! I want these Claims for this user: “User Roles”.  I am now going to redirect to you.
   2. STS: I see you want these claims, very well.  Give me your username and password.
   3. STS: Okay, the user passed.  Here are the claims requested.  I am going to POST them back to you.
   4. App: Okay, back to our own processes.
2. Once we have the Metadata, we add the STS as a reference to the Application, and call a web service to pass the credentials.
3. If the credentials are accepted, we get returned the claims we want, which in this case would be available roles.
4. If the user has the role to view races, we go into the Race view.  (All users would have this role, but adding Roles is a good thing if we needed to distinguish between wagering and non-wagering accounts)

One thing I didn’t mention is how we lock down the Data Service.  That’s a bit more tricky, and more suited for another post on the actual Data Layer itself.

So far we have laid the ground work for the development of a Race Browser application for the Windows Phone 7 using the Entity Framework and WCF Data Services, as well as discussed the use of the Windows Identity Foundation for authentication against an STS.

With any luck (and permission), more to follow.

Move Their Cheese! (and Change the Design)

I tend to complain a lot.  Which frankly, doesn't do much for what I'm complaining about.  In most cases, it comes down to "okay, here is a problem, now someone else go and fix it."  There is a direct correlation to how many people I annoy too.  The number of people I annoy increases as the magnitude of my complaining-ness (hey, a new word) increases:

If I wanted to change something, obviously I’m going about it the wrong way.  However, there is a direct correlation between how often I do something wrong and the likelihood I will get it right.  See previous image.  What that means is if I keep screwing something up, eventually I am bound to get it right.  However, what is not necessarily apparent in the chart is that if I do nothing, I won’t improve upon my actions.  Maybe it is apparent, I don’t know – I’m still working on it.

The reason I bring this up is because I keep hearing people bash/complain/hate the Office Ribbon and application Ribbons through Windows 7:

The major complaint has been that people couldn’t find what they are looking for anymore.  There aren’t any menus, so they can’t figure out how to set [insert obscure property].  It doesn’t make sense to them.  They now have to change the way they think about the application.  What is unfortunate about this is that menus are a horrible interface.  You shouldn’t have to dig through 6 layers of menus to change a single property, and that’s what Office 2003 became.  The Ribbon has it’s own problems, but it also increases user productivity greatly when the user knows how to use the Ribbon effectively.  Which in lies a major problem.

Most end-users don’t like when you move their cheese.

Well now we have a problem because people also want improved systems.  Improve the system, but don’t change it.  This paradox is why fundamentally different – game changing – designs aren’t seen all that often.  We stick with what we already know because if we deviate people will complain.  It’s a very tough way to create a better interface.

So how do you create a better interface?  You keep changing it.  Guaranteed the first couple of designs are going to annoy people: i.e. the Ribbon.

This is good.

If you keep failing at designs, that means eventually you are bound to figure out what kind of interface works best.  You will never figure it out if you never change.  Without MicroBating MasterSoft’s (hey look, two new words) ego, I must say that Microsoft is doing well in this area.  They keep making lousy design decisions.  See Expression Blend UI, and listen to most non-technical office workers using Office 2007.  I’m sure there are quite a few instances in other applications as well.  However, and I must make this clear, Microsoft is doing the right thing.  They are actively trying to create better interfaces.  Yes, it will piss people off (it’s pissed me off quite a few times), but at least they are making the effort.  And that’s what counts.

EDIT: P.S. I do like the Ribbon.

Zune Player

At first I was a little skeptical at the quality of the Zune Player, as it’s basically in direct competition with Windows Media Player.  In retrospect, that’s probably what made it what is today.  It’s designed to sync the Zune media player, and it works very well as an alternative to Media Player.  There are a couple problems that I have with it though:

• It’s a resource hog
• It requires a good video card to show effects
• It sorts things in weird ways when meta data is missing

The Zune Player is built on .NET.  It has a very big initial memory footprint.  It gets better as it settles into place.  My assumption is that it’s using WPF to make itself look pretty, and that’s where all the effects come from.  As a result some video cards aren’t capable of handling the effects renderings.  For instance, my laptop’s video card just dies when the effects are on.  Zune will turn them off if need be.  If the Album Artist meta tag is empty, Zune sticks “Various Artists” in place thereof.  Zune sorts based on Album Artist in the default view, so when I loaded my library into it, a whole whack of songs where under Various Artists, which isn’t all that useful.  With that being said, all the (legally) downloaded content had proper meta tags and were sorted perfectly.

However, with all the negatives, comes a few gems.  Sorting is a breeze.  Playlists are extremely easy to build.  Filtering works.  And it’s a really slick UI.

I’m a little miffed the band image is pixilated, but all the extra info brought with it makes up completely.  Talk about slick.

It also makes decent random playlist decisions.  On the UI and UX side of things it gets the job done.  It’s pretty stable.  It hasn’t blown up on me yet.  I give it my approval.  Check it out: www.microsoft.com/zune.

What Makes us Want to Program? Part 2

In my previous post I started talking about part of my personal history with software development, and when QBasic got me hooked.  I ended the post talking about the move to Canada.  We arrived in Canada literally a week (7 days exactly) before Grade 9 started.  After getting enrolled in school, I tried to find something to keep my mind occupied.  It was either that or contemplate what Grade 9 would be like for someone who used to live 3000 miles away in another country.  And winter.  Still 4 months away, but definitely something I didn’t want to think about.  Being that we moved to a house in the country, I couldn’t just walk around town either.  Mental occupation was harder than I thought.

So what does a 14 year old boy, new to the country, living in the middle of nowhere, do to keep himself from going crazy?  Install Linux of course!  I needed something to keep my interest, as well as to keep the gears in my head moving.  If memory serves, I started out with a vanilla copy of Red Hat Linux.  It was pretty easy to install, but being new to the OS architecture, the device mapping was a little confusing.  After a couple months of studying the Linux architecture, I started writing shell scripts, and even delved into the source code.  After testing some minor modifications to different components I started to learn the basis for the C/C++ languages.  Imagine that, a 14 year old kid understanding the basis for C++.

While trying to keep my mind still occupied, I came across an interesting find: The National Security Agency’s Security Enhanced Linux Kernel.  If compiled and installed wrong, you will destroy the build.  Learned that the hard way…  And seeing as I couldn’t find a proper driver for my modem anyway, I gave up on Linux and moved back to XP.  Not that the internet was all that useful anyway; I was connecting at 28.8 half the time.

Going back to the image in Part 1, I met an interesting character in school.  He turned out to be one of my best friends, and fellow developers, Greg. We started working on some odd projects here and there in VB, until I was tasked with building a web store.  Since I had never actually brought HTML and Dev together, I was a little nervous about what I was getting myself into.  Going with what I knew well, I started in ASP with VB code.  This was not ASP.NET.  Earlier, I had said I never found VB all that intuitive as a language.  The syntax never really made sense to me.  So my friend suggested I take a look at PHP as an alternative.  I liked it.

PHP had the flow of C, and the usefulness of VB.  With PHP I got the store finished and launched.  The site worked great.  I was 15.

Once the first spring of my existence in Canada rolled around, a couple friends and I decided to start a band.  We sucked.  But seeing as one of the other members was Greg, we had an awesome website.  We had media streaming, custom modified forums, and full site statistics.  The statistics were built around the forum.  The site pulled data from recent posts, recent events, and recent user logins, and compared the data to the media streams.  We could see who was doing what.  Mind you, there was only about 50 people who loitered around the site, but the site was a great proof of concept for what we could do.

Following the demise of the band, Greg and I were invited to a Microsoft hosted event.  It was here that I fell in love with ASP.NET.  Which I will discuss in Part 3.