I just implemented Windows Live ID SSO (single sign-on) enabled for our use case project - www.usefulcases.com
I would say that the framework itself is easy, though I ran into an issue due to a configuration issue on our part (not Microsoft fault)
The problem I had was that domain was configured to "foward" so the callback, which was made in HTTP Post, got translated to HTTP Get, loosing the "token" from the server during the course.
I could not get the "token" and had to ask Live ID forum for this *strange* behavior. I got a prompt response for troubleshooting... Of course, it was something we did wrong, so we fixed it.
If we didn't have the configuration problem then it would have been about 1 hour of work from nothing to a SSO. That's pretty good.
Here is the basic step (off my memory)
Go to https://msm.live.com/app/registration.aspx?wa=wsignin1.0 and enter data. Pretty easy stuff. One thing: you need to specify the URL of the callback page. If you use C# sample (see below), it is named webauth-handler.aspx, which you can rename to something else. It can be located anywhere but once you set it, you can't change the registration record (you basically need to re-register, which is easy so not huge deal).
Once the registration succeeds, you get an app ID value.
Download the C# sample at from http://www.microsoft.com/downloads/details.aspx?FamilyId=8BA187E5-3630-437D-AFDF-59AB699A483D&displaylang=en
The sample is a small web app.
Copy one .cs file in App_Code to your web site's App_Code. This is the library class. Also copy the entire Sample folder to your website. I put it under ~\FM\LiveID folder. FM stands for Federation Management. I intend to add YahooBBAuth, so created a subfolder called "LiveID".
Open the web.config in the folder you just copied.
You need to modify a couple of lines: one for app ID (you just got that) and a secrete (that you specified at registration)
That's it!
The default.aspx page comes with a iframe that shows the "login" link as well as a code to check for a cookie that would be created if SSO succeeds.
Login using the "login" link. You get the standard Windows Live ID login screen at Microsoft server.
When SSO succeeds, the default.aspx will show the "token" value. This value is constant and represents this particular user (or Live ID account, to be precise).
Now, I should try Yahoo! BBAuth (in fact, I've already obtained application ID. I will write about it later.)
1/30/08
What is Web 2.0?
I think I got it. I am sure I am late to this "hot" topic ;)
I have been trying to define "Web 2.0" in my own words. Until I do that, I don't feel comfortable even talking about it. People talk about it but rarely, it seems, understand what it stands for, and that included me until now (hopefully).
First of all, Web 2.0 is "a system that let users build a information mass which creates greater gravity to attract more information (via visiting users)"
The essense of gravity is "fundamental forces by which all objects with mass attract each other" as wiki articile says.
Unlike the physical gravity, in web world it is informational gravity: information (actually persons who posseses information) are attracted to a mass of information.
In addtion, Web 2.0 is "a system where information mass grows using both user-contributed assets, user-judgements, and user-activity events".
User-contributed assets are actualy not new to Web 2.0: it is any data user provides explicitly including things like YouTube video, discussion board statements.
User-judgements are indications of user's opinions, typically in the form of positive or negative feedback against data/information available. It includes "thums up" and "stars" you give to things like blogs.
User-activity events are completely implicit: if user adds a URL to a bookmark service, its action generates a statement, that becomes information, being broadcasted to other users. The fact that you watch a video in YouTube implicitly contributes to the build up of information - view count is a automatic voting mechanism.
Web 2.0 efforts should contain some, if not all, of these aspects.
I have been trying to define "Web 2.0" in my own words. Until I do that, I don't feel comfortable even talking about it. People talk about it but rarely, it seems, understand what it stands for, and that included me until now (hopefully).
First of all, Web 2.0 is "a system that let users build a information mass which creates greater gravity to attract more information (via visiting users)"
The essense of gravity is "fundamental forces by which all objects with mass attract each other" as wiki articile says.
Unlike the physical gravity, in web world it is informational gravity: information (actually persons who posseses information) are attracted to a mass of information.
In addtion, Web 2.0 is "a system where information mass grows using both user-contributed assets, user-judgements, and user-activity events".
User-contributed assets are actualy not new to Web 2.0: it is any data user provides explicitly including things like YouTube video, discussion board statements.
User-judgements are indications of user's opinions, typically in the form of positive or negative feedback against data/information available. It includes "thums up" and "stars" you give to things like blogs.
User-activity events are completely implicit: if user adds a URL to a bookmark service, its action generates a statement, that becomes information, being broadcasted to other users. The fact that you watch a video in YouTube implicitly contributes to the build up of information - view count is a automatic voting mechanism.
Web 2.0 efforts should contain some, if not all, of these aspects.
1/28/08
Use established icons
People are creative and artistic. When you design a software control/widgets, you may use various graphical represenations (glyphs and icons) to represent certain things.
When you pick icons for "actions", you should try to pick one that general population are used to. This is even more important if your icon does not accompany any text. (By the way, do not rely on tooltip/popup text for explanation - if something had to be explained, then it is already hard to understand)
+ and - (plus and minus) signs are established for indicating "expand" and "collapse" actions.
< and > (left arrow and right arrows) are established for moving "forward" and "backword".
x is established for "closing" a window/panel.
etc.
It is best try not to invent new graphical reprentations.
When you pick icons for "actions", you should try to pick one that general population are used to. This is even more important if your icon does not accompany any text. (By the way, do not rely on tooltip/popup text for explanation - if something had to be explained, then it is already hard to understand)
+ and - (plus and minus) signs are established for indicating "expand" and "collapse" actions.
< and > (left arrow and right arrows) are established for moving "forward" and "backword".
x is established for "closing" a window/panel.
etc.
It is best try not to invent new graphical reprentations.
Learning Usability from mini-van
One of the important aspects of "software usability" is to minimize the number of user actions such as mouse-click and enterying a key.
It is obvous that fewer is better, but when and for what feature is it appropriate to make it fewer clicks? Well, you have to figure it out by seeing what users do: what is the goal user is trying to accomplish? Does certain gesture tells us about the user goal?
I have a mini-van for my family and learned one essence of how to think about user goals. I have a key (obviously) and when I insert the key to door at the "driver's side", if I turn the key once, it opens the driver's door, and if I turn once more, then it opens "all" doors. So, it takes twice to open all doors.
In contrast, if you insert the key at the passenger's side door and turn once, "all" doors open. Appearently, the similar "door opening" mechanism is configured (programmed?) differently.... why? It's is because the chances are the if someone is opening the passenger's side door, it is likely that a family members are getting to the van. However, if someone opens the "driver's door", it is somewhat more likely that it is just you, driver, who wants to get in.
These are similar to the number of mouse clicks. If you study the "situations" underwhich your software is used, and if certain gestures strongly indicate certain user goals, then system should be programmed to achieve the goal in the least amount of user actions.
It is obvous that fewer is better, but when and for what feature is it appropriate to make it fewer clicks? Well, you have to figure it out by seeing what users do: what is the goal user is trying to accomplish? Does certain gesture tells us about the user goal?
I have a mini-van for my family and learned one essence of how to think about user goals. I have a key (obviously) and when I insert the key to door at the "driver's side", if I turn the key once, it opens the driver's door, and if I turn once more, then it opens "all" doors. So, it takes twice to open all doors.
In contrast, if you insert the key at the passenger's side door and turn once, "all" doors open. Appearently, the similar "door opening" mechanism is configured (programmed?) differently.... why? It's is because the chances are the if someone is opening the passenger's side door, it is likely that a family members are getting to the van. However, if someone opens the "driver's door", it is somewhat more likely that it is just you, driver, who wants to get in.
These are similar to the number of mouse clicks. If you study the "situations" underwhich your software is used, and if certain gestures strongly indicate certain user goals, then system should be programmed to achieve the goal in the least amount of user actions.
1/23/08
Self-testing class
I am not sure how popular this idea is. Wikipedia does not have much contents in this topic.
Self-testing code - Wikipedia, the free encyclopedia
I have always been thinking about effective ways to write classes that can be tested easily. I've tried NUnit, which works just great. One drawback was that it is not easy to test protected methods.
I've also tried Visual Studio Team System's unit test feature, which also works great. It comes with IDE integration so generating test scheketon is a matter of several mouse clicks. It also supports generating "accessors" that would use Reflection to invoke protected members. However, it is still somehow not of my liking. Besides, I use Visual Studio Developer edition for my personal projects and unit test feature isn't just available to me.
Then, I started tying out "self-testing code".
I am still experimenting but it seems to be effective. Here is how you would do it.
Whenever this class is used, the static constructor runs self-testing code, provided that it was compiled as Debug build.
The condition can be tweaked to use configuration settings. For example, app.config's appSettings can have a key-value pair: TestHello=true
That way, we can control the self-test execution independent of build target.
My projects are small, done by few people (my game is worked on by just me and my friend - and another new project is by four of us). Because of the size of the projects, there is not dedicated QA resource - not that I am pushing the responsibility of testing entirely to QA, but my point is that importance of uint testing increases ever more.
For such small development environment, self-testing strategy might be OK.
Self-testing code - Wikipedia, the free encyclopedia
I have always been thinking about effective ways to write classes that can be tested easily. I've tried NUnit, which works just great. One drawback was that it is not easy to test protected methods.
I've also tried Visual Studio Team System's unit test feature, which also works great. It comes with IDE integration so generating test scheketon is a matter of several mouse clicks. It also supports generating "accessors" that would use Reflection to invoke protected members. However, it is still somehow not of my liking. Besides, I use Visual Studio Developer edition for my personal projects and unit test feature isn't just available to me.
Then, I started tying out "self-testing code".
I am still experimenting but it seems to be effective. Here is how you would do it.
public class Hello
{
static Hello()
{
#if DEBUG
// add code to test features of Hello class
#endif
}
public void Foo() { }
public void Bar() { }
}
Whenever this class is used, the static constructor runs self-testing code, provided that it was compiled as Debug build.
The condition can be tweaked to use configuration settings. For example, app.config's appSettings can have a key-value pair: TestHello=true
That way, we can control the self-test execution independent of build target.
My projects are small, done by few people (my game is worked on by just me and my friend - and another new project is by four of us). Because of the size of the projects, there is not dedicated QA resource - not that I am pushing the responsibility of testing entirely to QA, but my point is that importance of uint testing increases ever more.
For such small development environment, self-testing strategy might be OK.
Subscribe to:
Posts (Atom)
