| Comments

i've spoken a few times about axosoft.  they are a local ISV that does some great work.  their ceo, hamid, does a great thing every year for his employees (maybe more often) in encouraging and icubating new projects.  they have a core product, but also have incubated some great ideas.  some haven't lasted, but some live strong!  either way it is great to see what kind of ideas their group comes up with.

PureChat is one of those new ideas.  this is an idea that was just released.  it is for asp.net sites and is built using c# and asp.net ajax as well as the ajaxcontroltoolkit.  one of the developers, jonas, writes:

PureChat is written entirely with C# and javascript, against the 2.0 .NET framework. It uses Microsoft's ASP.Net AJAX, as well as selected controls from the AJAX Control Toolkit. Before I go any further, I just want to say that the Atlas (I think I'll always call it Atlas, it's shorter and sounds better) javascript framework really adds a lot of value and productivity for doing any sort of extensive work in javascript. Major kudos go out to that team at Microsoft. (emphasis mine)

very cool.  i just downloaded the free single operator key (this means operator, not incoming chatters) and installed onto my site in < 10 minutes.  i can't get it to play nice with subtext right now, but i'm going to see if the subtext list can help me out (httphandler collision and all).  as an operator i get a complete operator panel that gives me:

    • view of all chats
    • access to transcripts of chats
    • abandoned chats
    • multiple chats

it looks like this:

the end user gets a chat window they communicate with which looks like...well, a chat window.  what's cool is there is nothing for the user to install, and this runs in the browser using asp.net ajax technology.  i was really glad to see jonas' comment about how that framework enabled a lot of things a lot easier for him...that is good to hear.

so if you want to enable web-based chat on your site, you can get a free single operator license or right now they are doing a promotion for $5 for a 5-operator license.  this would be great if you need to provide online customer service in your site/application.  i don't think the intent is to put it on a blog (personal) or anything...at least i don't think that would be a good scenario for me i should say.  the operator has to be logged in.  but for scenarios where you have a product and customers, it would be a good thing to quickly add to your site (or product) and be able to directly communicate with your users.

good work axosoft...i can't wait to hear some behind-the-scenes stories on how it was to leverage the ajax framework for asp.net!  maybe they can add a silverlight UI at some point :-)

| Comments

recently i've been getting a few notes/questions about working with web services and asp.net ajax.  my colleague, rob bagby completed a series of great web casts last year covering the topic of the ajax libraries in detail, one of which deals with web services.  there are also two webcasts that deal with calling WCF services using the ajax libraries.  i highly recommend checking them out!

| Comments

today, the iis team released a preview of the 'web deployment tool' for internet information services (iis).  the tool has features that a lot of server admins would want such as deployment assistance, sync/migration of sites across servers (which includes config, content, certs, etc.).

the core features are:

    • synchronization and snapshot of IIS 6/7
    • migration from iis 6
    • analysis of iis 6 installed features
    • troubleshooting and validation features

go check out the post for all the details and a download link.

| Comments

the leaders of the have convinced that phoenix is nice in march (and it is...spring training baby!) and he should visit.  they've organized a super user group meeting and you can find information on when/where here.  it will be hosted at scottsdale center for the arts, which is a pretty killer facility.  i'd recommend carpooling and not messing with the no parking signs (those scottsdale folks like to watch those meters).

having ScottGu come to phoenix immediately after MIX08 is a great thing for the community.  if you couldn't make it to MIX, you'll be able to see some new things from scott in what no doubt will be an exciting, new and learning experience.  there are some great things coming out of his group at MIX and this event in phoenix is a must see.  i'm sure he'll cover some great new web stuff, updates on and we'll all be enlightened by how he still manages to stay close to the code while serving a growing army in the developer division!  be sure to block your calendar now!

i know scott won't be able to cover everything, so we'll ensure that will cover some of the gaps.  be sure to subscribe to the feed to know when we'll be coming back through phoenix -- we'll be updating it soon!

| Comments

recently i came across a feed entitled '.aspx considered harmful' and natural i paused.  for those who don't know .aspx is a known file extension for web pages generally using asp.net technology.  i think the title was a little misleading but it did the job -- got me to read it :-)

john had made a suggestion in conversation that a blog engine (must have been the topic of conversation) shouldn't produce urls that end in .aspx.  basically, in a nutshell john is pointing out that technology changes and while you might be .aspx one day you might be .php the next.  valid point.  where i think his argument breaks down for me is in the two reasons he points out why this is 'harmful': futureproofing and style.


let me take on futureproofing first.  john's assertion is:

"The technology that produces the name, never mind the version of that technology, is a variable that need not, and should not, be exposed. If links are pointing to foo.asp, and your upgraded blog engine produces foo.aspx, you broke those links. That’s unnecessary and avoidable."

for me that is a pretty big leap.  aside from the fact it puts a lot of weight on the technology implementers to forever future-proof their technologies (web ones being in question here).  i'm definitely not disagreeing that you need to do your best effort to future-proof information...that is what makes internet information so valuable...it's longevity.  i disagree with the assertion that file extensions are the cause of problems -- it is more like sloppy editors.  the point here is to respect the permalink.  i'm in the camp of 'who cares' when it comes to file extensions.  if an author of content is moving from one platform to another, it is their responsibility to respect the permalink to the information.  i may have bookmarks, etc. that i rely on.  don't 404 me bro!  john does point out that the new asp.net mvc pattern can help things like this for eliminating .aspx in the url.  i guess i'd be quick to point out that it doesn't solve the problem at all posed in the futureproofing note.  so now i have 'clean' urls...great, what if i now move to a framework that doesn't support mvc/rest-esque url patterns?  i'm just as screwed.  i'll say it again, respect the permalink

i'll take an example from one of my colleagues.  dave bost hosted his blog on an asp.net technology for a long time.  he built up a lot of those harmful .aspx things over time.  when dave decided to learn some new technologies, he decided to move to a php-based blog engine.  wow, those dangerous .aspx are going to leave some nasty end trails moving to php.  or not.  you see, this would be more of a move from an older microsoft technology to a newer one.  this is moving from microsoft to non-microsoft.  what would he do?  dave knew he had to respect the archive he had.  so users who may have bookmarked a url to http://davebost.com/blog/archive/2007/06/14/Gadgets-and-Snipping-Tool.aspx will not have lost the information.  see dave.  see dave respect the permalink.  thanks dave.  if you click that link above you'll notice that you'll end up at http://davebost.com/blog/2007/06/14/gadgets-and-snipping-tool which is the current url.  having .aspx wasn't harmful because the author of the content was responsible to ensure that permalink wasn't lost.  now i'm not saying it was drop-dead simple, in fact i don't know how dave decided to do it, but he did.  his readers (and search engine archives) will not be lost because he moved to a different technology.  it didn't matter what the endpoint extension of the url was.  didn't matter at all.


on the context of style, john writes:

"Names without extensions are cleaner and simpler. Why does that matter? I guess if you think of URLs as constructs generated by machines for machines, then it doesn’t, because machines don’t care about style. But I believe that even when they’re machine-generated, URLs are for people too. We read, cite, and exchange them. Their structure and content conveys meaning in ways that warrant thoughtful analysis. Elements that don’t convey meaning, and that detract from clarity, should be omitted."

again, here i'll disagree (of course, or what is the point on writing this post).  whenever i see comments like these i always slow down and defer to the mother-in-law factor.  you see, we in technology have a tendency to think that things must make sense.  users generally don't care.  they want things to work.  when they bookmark things they want them to be there.  when they search, they want to find.  etc.  with regard to style, i think it seems a bit nitpicky.  for me content is king.  why should i care what the url is as long as the content i'm looking for/reading/consuming somehow is valid to me.  does it make it less valid because the url looks technical?  look at facebook.  my profile page is http://www.facebook.com/profile.php?id=584375671.  sure, that url does nothing to tell me what profile i'm about to see.  it would be cool, i guess, to see http://www.facebook.com/profile/timheuer, but i don't really care.  you see i can easily ensure my content says view my facebook profile.  there, do you see the url muck?  no, you see a hyperlink to something that i've described.  and when you click it you know what you are getting...so who cares about the url?

john's note about 'elements that don't convey meaning, and that detract from clarity, should be omitted' is something i disagree with.  to *something* they have meaning.  look at yahoo.  this url http://news.yahoo.com/s/ap/20080118/ap_on_go_pr_wh/economy_stimulus goes to an article about president bush and some tax stuff.  should the url have been http://news.yahoo.com/Bush-wants-fast-tax-aid-to-boost-economy?  who knows.  i'm sure there is a content management system behind their solution that is at 'fault' for creating the url.  whatever the reason, i don't care -- the content is king.  i can see somewhat john's point that we can't always blame technology like i just did.  sure a content management system should be able to let me name whatever i want.  but i guess that is a technologist thinking again and not my mother-in-law...she just wants to read the article.

another piece of evidence to this is a commenter on john's blog:

"If I see a file of the form http://example.com/path/to/file.rss I expect the result to be an RSS feed." source

wow!?  i think i'm going to ask my dad tonight if he knows what .rss is.  that is a technologist thinking if i ever saw one.  another commenter notes that urls are brands:

"Absolutely. URLs are brands, permanently on display for every webpage. The user wants to know what the page is about, not what technology you’ve used to put it together." source

i agree with the first statement here.  it is why i blog on timheuer.com and not blogs.msdn.com -- this is my brand.  i would argue 'root brand' is important here.  the user wants to know *where* they are reading the information.  they will remember their own context of the content.  i'll take the yahoo link above as an example.  having news.yahoo.com is critical because it is their brand and reminds me of where it is.  but i won't take the time to really record the rest of the url.  i'll either bookmark it for later if it is interesting or in passing i'll mention to someone 'i read an article on yahoo about bush and tax aid, you should search for it.'  that is how we talk now.  'just google it' is a common phrase.  we use things like tinyurl, shrinkster, etc. to shorten urls for us to make them easier to send. 

urls aren't the only place where this is.  would john suggest that we do away with .exe, .app? 

you see to me, the technology isn't harmful.  the style of implementing human readable urls isn't harmful (or sometimes isn't even helpful), but respecting the permalink is critical...no matter what technology is used.  it matters not what the address bar says, but rather that i can find it when i search for it and when i save a reference to it.