I was looking at wikis recently and thought I'd list out the ASP.NET wiki's I've noticed. Obviously there could be more, but here are the one's I've seen:

• FlexWiki -- been around for a while, easy to install & use.
• ScrewTurn -- has gotten some good buzz recently, seems the most active recently w/ a number of interesting features.
• Perspective -- I recently noticed this. Has a WYSIWYG editor (which I think is good for corporate adoption). You can also attach & embed files (e.g. Microsoft Office Docs) & images, & search across them. Seems like it might be complicated to set up & install.

I believe they all can do authentication/authorization through NTFS and/or LDAP, so you can administer the permissions like you would any other IIS web site.

Here is a WikiMatrix comparison page of the above three wikis, although I don't believe their information is completely current.

photobucket has a photo-sharing widget that you can plug into your site, allowing your web site visitors to upload, access, and share images from their Photobucket account.

Granted, users need a Photobucket account to use it ... I wonder if the widget makes it easy & transparent to sign up?

I posted this because MyPunchBowl lets you share photos from flickr, but if you don't have a flickr account, you're out of luck.

Programmable Web posted a blog about tools to create mashups. For example, Dapper and OpenKapow make it easy to create web services based on scraped web sites.

And, I made a new category called Web. :)

Check out Vertigo Software's Cliff's Notes for a Team System Install. It'll walk you through setting up Microsoft's Team System so you can see what all the fuss is about and finally get away from Visual SourceSafe.

Smashing Magazine came up with a link-list post called 53 CSS Techniques You Couldn't Live Without. It links to cool CSS effects that are easy enough to add to your web applications. Developers (like me) are notorious for being, hmm, spartan when it comes to design, so ready-to-go script that lets me jazz up my pages is welcome. Plus, Smashing included little screenshots of the effects, so you don't have to click through to see what they're like (though a few of the screenshots don't really explain the effect well [I'm talking to you, Link Thumbnail]). Anyhow, here's images of a few:

CSS Teaser Box

CSS Ratings Selector

 

I was reading TechCrunch today and noticed an article about booBox, a lightbox product that allows Amazon affiliates to incorporate cool web-2.0 "popups" with Amazon.com products into their site. I often read about startups on TechCrunch, and sometimes I think to myself "man, I wish I had thought of that" or "man, I could do something like that."

Well, today the barrier to entry was so low that I came up with a competing product in under an hour. And not only that, but I'm offering three times the options! And did I mention it was free? So I give you ... the DevelopmentNow Amazon GreyBox!

For demo and code, go here.

This is a real life example of what I was getting at in my Social Networking for Sale post -- with rapid development techniques, open source software, and the huge availability of turnkey widgets, code samples, and solutions, product development is becoming increasingly commoditized, allowing the easy output of "close enough clones." A previous employer had experience with a competitor whose product was "close enough" to be a real competitive threat, and so winning clients was less about the actual product than the strength of the team, marketing, PR, customer service, existing client list, and sales power.

So do I think that I'll be a serious competitor for booBox? Probably not, unless I put together a hip-looking web site, send out press releases, work the conferences, etc. And competing with them wasn't really the point. Rather, since Mike Arrington gave booBox "an early thumbs up" and said it "may be quick acquisition bait for Amazon or eBay," it seems there's potential gold even for quickly-developed apps.

Granted, I were serious (or smart?), I probably should have said my product took weeks/months to develop, not minutes/hours. And instead of using my product to prove a point on the commoditization of software in a little-read blog, I should have instead used it to go for either some web 2.0 notoriety and/or a quick-hit acquisition. But ah well. :)

booBox

DevelopmentNow's Amazon GreyBox

A question came up recently on a mailing list I'm on about virtual machines for production applications. I've used virtual servers for web & database apps before, but only for dev/qa purposes. It made it much easier to go through deployment scenarios, try out new builds & roll back if the install failed, & generally avoid the time & money sink of dealing with setting up & maintaining actual physical machines. Plus virtual machines are easier to throw onto more powerful hosts as your needs grow.

However, if your organization is considering virtual machines for their production apps, they're in growing company. Most of my experience with production apps has been to start with traditional shared hosting plans, then move up to dedicated machines. That approach works especially well if you only have a few web apps that can all run on the same machines, or if your CPU needs are high.

However, using virtual machines (aka virtual servers or virtual private servers) can be a good way to save money if you have a number of heterogenous and/or legacy applications that need their own "server" (for security, configuration, manageability, specific OS requirements, or other reasons) but don't have very high horsepower needs. In that scenario, having a separate physical machine for each app can be costly overkill, and require you to answer repeated questions from your boss like "why did we need to buy and maintain 5 new servers when they're all under 10% utilization?" 

Instead, you can have each app on its own virtual server, and put them all on one or more physical machines -- however many are needed to run the apps effectively. Costs are reduced since you have fewer machines to power, watch, store, and maintain. Scaling applications can be simplified since you can allocate more or fewer resources to specific vitual servers, and you can always move them onto other, more powerful physical machines as your needs grow. Plus, disaster recovery can be easier, since if you have a hardware failure, you can just load the virtual server onto a different machine and keep on truckin'.

VMWare has some good info on their site: http://www.vmware.com/solutions/home.html

So does XenSource (Xen is open source virtualization software) http://www.xensource.com/solutions/ 

And I might as well link to MS Virtual Server, which apparently is free(?) :) http://www.microsoft.com/windowsserversystem/virtualserver/evaluation/vsoverview.mspx

Plus there are some other links around the web if you search on "virtual server" or "virtual private server."

I heard a rumor that Aptana is a great editor for JavaScript. I haven't tried it, but Rick Strahl likes it, which is a good kudo in my book. Editing JavaScript in Visual Studio is "okay," not great, so I welcome a better editor.

Aptana's site also has a bunch of great video tutorials, for those of you who want webcasts.

Aptana Screenshots

"Code Assist" (Intellisense) for JavaScript, CSS, & HTML:
  

 

more and larger screenshots >>

Well, I may have to start up a social networking category. I ran across Shuzak, a "social network for geeks." While the idea of niche-based social networks (or vertical social networks: VSNs) isn't a stunner, it doesn't seem very common yet. I'm sure we'll see many more in the upcoming year.

Shuzak seems interesting, but at first blush it feels less like a targeted MySpace and more like a BBS with extended user profiles. Like a custom Zoints Local app. I do like the fact that they're not just a generic social network, though ... they have a few features specific to their theme (e.g. syntactical code highlighting, mathematical equation formatting). I could maybe see this taking off in a university, allowing professors to set up private, invitation-only "classroom social networks" to allow their students to collaborate on projects, exchange notes, ask questions, etc. There ya go, Shuzak, I just gave you your in. :) Ofc, you probably already thought of that.

Anyhow, when one (like me) talks about a social network being a BBS with better profiles, is that a bad thing? How exactly does one define a social network? Is it features, e.g. profiles, groups, and buddy lists? Or is it purpose, e.g. exchange ideas, send messages, meet people? And if it's purpose, does that purpose have to be intentional (e.g. using eHarmony to find dates), or can it be incidental, as with the countless friendships forged in MMORPGs? Could you argue that other, existing sites that are centered around communication (forums, social bookmarking sites that allow comments) are social networks, too? Mashable sure did by mentioning Digg as a techie social network.

I will say, though, that looking enough "like MySpace or Facebook" will probably make it easier to get funded.

When you embark on a web redesign project, it's important to ask your client open-ended questions to get some ideas on what they want to accomplish with their new site. You want to learn about their users, their goals, and what's important to them. From there, you can start thinking about the information architecture of the new site and potential designs.

Here's a partial list of questions you can ask (mostly courtesy of Scott McMillin):

• Why are you re-designing your Web site?
• What goals do you have for this re-design?
• What are your company's core values? What sets you apart in your industry?
• What do users need from your Web site?
• Is there any information your users are having trouble finding?
• Describe your typical user. Do you have different types of users who need different things?
• Can you provide any aggregate data on your users, both demographic and technical?
• If you could only put three pieces of information on your home page, what would they be?
• List some Web sites and/or specific pages that you feel are effective in communicating the feeling or message that you want your site to evoke. How and why are they effective for you?
• Do you have a logo or logotype that you want to use? Do you have identity or branding standards that must be adhered to?
• Have you gotten user feedback on your current site? If so, what have you learned from that feedback?

 

As I mentioned in Social Networking for Sale, I believe social networking software/sites (SNS) will become pretty commoditized in 2007. It's already pretty cheap & easy to get your own community site.

For example, there's Scuttle, open source social bookmarking software. If you need social networking software (a la MySpace), you can find it for free/open source with Alicia (aka PHPizabi) or AroundMe or osDate or Yogurt or Dolphin.

If you want a fancier MySpace clone you can spend $300 or so for phpFox or Handshakes or BuddyZone or webNetwork or Elgg Spaces or SocialEngine or a dozen others. 

There are also hosted, turnkey solutions like PeopleAggregator, Me.com, Ning, Pringo, KickApps, and others, which offer plans ranging from free to paid.

There's also a social networking addon for vBulletin called Zoints Local -- plug it into your existing vBulletin site and bingo! instant "community."

And of course there are "community" addons for CMS+ platforms such as phpNuke, Joomla (Community Builder), Drupal, etc. allowing you to truly build your own SNS. One could also do it by hand using Rails or some other rapid dev platform.

No matter which option you choose, you have a number of customization options, not all of which require a programmer.

The point of all those links is to reinforce the fact that there's already a slew of cheap starting points for a social community site for would-be MySpace topplers. I figure there will eventually be a number of vertical social networks (VSNs) for gamers, hobbyists, flyfishermen, cheerleaders, etc. Maybe they'll be within MySpace, or maybe third party sites. Better yet would be if VSNs could integrate with people's existing social networks elsewhere on MySpace, Facebook, LinkedIn, etc, so that you don't have to abandon your friends, profile, and blog posts to tap into a more targeted community. People would be more likely to join a new social network if they didn't have to reupload all their photos, reanswer all their profile questions, etc.

PHPizabi Alicia

 

Boonex Dolphin

OSDate

Zoints Local

Normally one would think that adding a new, unused column to an existing database table wouldn't break anything, right?

Well, normally it wouldn't, unless the column name is the same as on another table, and if some of your queries don't use the table.column syntax when referring to columns.

For example, assume you have two tables with a many-to-one relationship:

Employee
EmployeeID
EmployeeName
DepartmentID
Active

Department
DepartmentID
DepartmentName

Notice that the Employee table has an "Active" column, but the Department table does not.

Down the road, you decide to add an "Active" column to the Department table, too. You figure since it's a brand-new column, it shouldn't break anything. However, if your application uses queries like this:

SELECT EmployeeName, DepartmentName, Active
FROM Employee e INNER JOIN Department d ON e.DepartmentID = d.DepartmentID
WHERE Active=1

they'll break with an "ambiguous column name 'Active'" error as soon as you add an "Active" column to the Department table, because now the "Active" column in the above query is ambiguous: does it refer to Employee.Active or Department.Active?

The solution to all this is establishing some good naming & query-writing habits:

1. If you're going to add a new column, do a search to see if other tables have columns with the same name (e.g. "select * from syscolumns where name = '<columnname>'" on SQL Server). If they do, double check procs & queries.
2. Try to use specific column names, e.g. EmployeeName instead of Name. That'll reduce the change of conflict, as well as make the field names, proc parameters, etc more self-documenting.
3. Make a habit of always using the table.column name convention in queries. So the above query would instead be written as
   
   SELECT e.EmployeeName, d.DepartmentName, e.Active
   FROM Employee e INNER JOIN Department d ON e.DepartmentID = d.DepartmentID
   WHERE e.Active=1
   
   which would then protect it if the tables get new, ambiguously-named columns in the future.

I've been talking with different clients about building social networking sites. What I'm hearing more is the interest in specialized or vertical social networks (VSNs). Then what I hear is "so, how much would it cost to build a web 2.0 social network for <insert niche here>?" The answer is: it's getting cheaper all the time. The second, less-expected answer? That cheaper-to-build social networking sites isn't necessarily good news for would-be MySpace killers.

Interestingly, I noticed that mashable had a link indicating that ruduzu, the "anti-social networking site", is for sale. The winning bidder gets all the code, the existing community (all 273 of 'em), and one year of hosting. So far the bid is up to $3,800 with 15 days to go, so it's possible that potential MySpace killers can get their very own social site for well under $10,000!

I do think that plug & play social networking features (social widgets?) might be more popular in 2007. TechCrunch already talked about a comment system that could be quickly embedded in any site. I blogged about Plaxo's Address Book Widget making it easy to add all your buddies to a new social web site (and I wouldn't mind being able to import actual buddies from other social networks, too). So I'm sure we'll see other widgets (instant photo gallery! instant blog! instant buddy list!) this year, along with a huge crop of rapidly developed (and probably rapidly abandoned) "web 2.0" sites.

Thus comes my real point -- I think the base technology is becoming more of a commodity. I believe it's getting easier than ever to develop software and web sites, and developers are more reluctant to reinvent the wheel. Which IMO means two things

• the barrier to entry for crappy "me too!" sites will continue to get lower
• the differentiators will be (as in the past):
  • continual improvement & innovation
  • ability to raise and manage capital
  • ability to market and make deals
  • ability to serve up interesting content 
  • hard, continued work

So in 2007, if you wanted to knock out a quick & dirty MySpace clone in a few weeks, you probably could. You could make a Google Maps mashup in under a week. Maybe even build a deli.cio.us knockoff in a few days.

But if you want those sites to be something other than resume fodder, expect to put in some hard time. The days of "build it and they will come" are gone. If they ever existed at all.

Noticed James Edwards' article on SitePoint about developing javascript-powered sites that still work for screen readers. It had some good points, such as thinking in terms of device independence, using input elements (anchors, buttons) to trigger actions, and using behavioral pairing instead of event pairing.

Although, I think the example of "accessible drag n' drop" could have been phrased a bit better. Since it was an article about javascript, I realize that James meant "accessible drag n' drop" to mean "Drag & Drop by mouse or by keyboard." But I was a bit bothered by the idea of "Drag & Drop" as a feature. I would argue that "Drag & Drop" isn't a feature per se, but more of an interaction or control mechanism. "Ability to rearrange or sort elements on your personal home page" is a feature, and "drag & drop" can be one (non-accessible) means to accomplish it. While this may seem like (and be) nit picking on my part, I bring it up because IMO I think it's important to differentiate user goals from how they achieve them. The user doesn't want to "drag and drop", they want to "rearrange their home page." That's the user's goal, which we can then start thinking about how to best accomplish for all types users (mouse users, keyboard-only users, screen reader users).

Thinking in this manner (goals first, then how to accomplish it for a given user base) means that you don't have to take on the task of "making drag & drop work for screen readers" -- you just need to allow VI users to rearrange their home page, which might have nothing to do with drag & drop at all! Indeed, the way I thought of doing it would be to have a hidden (or not) button or two on each home page element allowing the user to move it to the top, bottom, or up/down one spot in their home page hierarchy.

I should also mention that "accessibility" isn't just about sighted vs visually impaired users -- it's about making features accessible to a certain type of user. James makes a great point about this in the first two sections (Keyboard Navigation? and Device Independence!). For example, some users don't or can't use a mouse, and instead use a keyboard to surf the web, so a site should still ideally be usable to them. In the example of keyboard-only users who are not visually impaired, I could see a keyboard-driven version of drag & drop, where the user "drives" a div around the screen via the arrow keys. Maybe this would be for an online game or drawing application where you have to position things in a specific way (put a hat on a person's head, or position a pair of glasses on a face). In that case, the interface for visually impaired or blind people might be totally different, if they're even interested in the application at all. They may not be, which is why it's important to consider your potential user base.

James also links to an interesting accessible crossword puzzle by Derek Featherstone. If you look at the source code you'll see a number of useful elements & tricks for accessible sites: fieldsets, labels, "hidden" text.

So...I really just meant this to be a "hey link over to this interesting article" post, but I guess I got carried away.