I came across Unfuddle today. It's an ASP model that offers hosting for project management tools, source code, and bug/issue tickets. Plans range from free to $100/month.

I've been looking for a simple bug tracking solution, and while Fuddle may not be the right way to go (for me), it seems like an interesting offering. They use Subversion for source code hosting, and a Rails-built platform for managing projects, tracking to-dos and milestones, handling bugs and feature requests, entering time spent, and keeping a project moving along. Might be a good option if you have a small team of developers and don't want to deal with setting up a source code repository, and you're tired of emailing Excel spreadsheets around.

Note that hosting companies like Dreamhost offer easy Subversion setup, but AFAIK don't offer the other stuff -- issue and project tracking.

Ok, I'm not a designer, I'm a developer. So tips that are new to me are often old hat to my designer friends.

Nonetheless, I put tips out in hopes that they'll be as helpful to me as they are to other non-designer developers who are still often called upon to put together a simple site that still looks decent.

So, I was looking into rounded corners today. You know, the cool hip rounded stuff you see on every Web 2.0 site. So I found Smiley Cat's CSS Rounded Corners Roundup, a big list of rounded corners techniques. What I liked is that many of them had online generators, so I could type in some parameters (color, size, roundedness) and be given the exact HTML, CSS, and images I need to pull off my cool rounded corners effect.

For example, I got this from roundedcornr.com:

I also ran across a javascript/css-only version called Nifty Corners Cube. Since it only uses CSS and javascript to give rounded corners to DIVs, no images are needed, and the latest version of NiftyCorners lets you do other stuff like rounded menu tabs, or complex layouts.

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. :)

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.

I noticed a different kind of WYSIWYG editor today (credits to Brian R) called WYMeditor. It strives to provide an easy-to-use content editor for non-technical users, while keeping the formatting options to a minimum. It's actually dubbed as a WYSIWYM (what you see is what you mean) editor, and outputs XHTML for easy insertion into CMS systems. Plus, it's open source, and very lightweight. 

Their words:

WYMeditor's main concept is to leave details of the document's visual layout, and to concentrate on its structure and meaning, while trying to give the user as much comfort as possible (at least as WYSIWYG editors).

I like the idea behind WYMeditor, because it strives to avoid my beefs with many existing content editors:

• Many common WYSIWYG editors allow too much control over the content, allow users to paste in horribly-mangled HTML from Word, etc., and/or output HTML that's laden with inline styles, extra formatting (extra breaks, tables, non-breaking spaces), and not XHTML. The content often "looks ok" in the editor, but then doesn't work out well in the site. Or, the layout can get "messed up" in the editor, but since the user doesn't look at or understand the underlying HTML, he or she isn't able to fix the formatting issue without deleting all the content and trying again. Lastly, trying to clean up the editor's HTML output & insert it into an existing page template can be tricky and leave you with a funny-looking page.
• The other direction, using a text-only editor with special characters for formatting (like many wikis do) minimizes problematic formatting, but is less natural to non-technical users who are expecting something to "look like Microsoft Word." And I don't blame them -- Alan Cooper wrote in one of his books about how often programmers forget to design interfaces that work the way users are used or and/or expect them to, and how that can cause unexpected usability issues or other problems. Not that we should never offer anything new to users with old habits, but...well you know what I'm getting at.

However, WYMeditor is still young, barebones, & has its share of issues (no nested lists, certain browser compatibility, trouble deleting HTML tables, etc). Still, WYMeditor might be a good option now or in the future, depending on your audience and application.