home · blog · groups · about us · contact us
DevelopmentNow Blog
 Monday, January 15, 2007
 
 

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.

January 15, 2007    Bookmark to Digg or other social bookmarking
#    Disclaimer  |  Comments [0]



 Sunday, January 14, 2007
 
 

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?

 

January 14, 2007    Bookmark to Digg or other social bookmarking
#    Disclaimer  |  Comments [0]



 
 

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, NingPringo, 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
dolphin.png

OSDate
osdate.png

Zoints Local
Zoints Local

January 14, 2007    Bookmark to Digg or other social bookmarking
#    Disclaimer  |  Comments [2]



 Thursday, January 04, 2007
 
 

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.
January 4, 2007    Bookmark to Digg or other social bookmarking
#    Disclaimer  |  Comments [0]



 
 

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.

January 4, 2007    Bookmark to Digg or other social bookmarking
#    Disclaimer  |  Comments [0]



 
 

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.

January 4, 2007    Bookmark to Digg or other social bookmarking
#    Disclaimer  |  Comments [0]



 Tuesday, January 02, 2007
 
 

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.

 

January 2, 2007    Bookmark to Digg or other social bookmarking
#    Disclaimer  |  Comments [0]



 Thursday, December 28, 2006
 
 

It's been a bit since I last wrote, but I wanted to write a quick piece about New Year's Resolutions.

At the end of every year, many of us look back at the past year and try to come up with things we'd like to do differently in the coming annum. Dieting and exercise are probably near the top of most people's personal lists, of course, but I think setting some resolutions can also be good for your career.

Like any good goal, a resolution should be something realistic and achievable. Ideally it should be specific (e.g. "exercise at least once a week" instead of "exercise more") to allow you to measure your progress. And of course you should have a timeframe in mind. Often it's just "before the end of the year" but sometimes it's something different. But you should also allow yourself to adjust your resolutions, and give yourself a chance to redeem yourself if you mess up. Get someone else involved (friend/partner/coworker/accountant) so they can cheer/nag you on. And yes, the emphasized words above fit into that handy goal acronym -- S.M.A.R.T. -- that I discussed a while back on setting goals.

Resolutions should be something that are important to you. Think back about the missed opportunities over the past years. Think about what you wish you accomplished but didn't. Think about how good it'll feel to cross those things off your list, and look back, a year from now, feeling better about yourself and your career. Force yourself to consider the above reasons every day, and you'll be further towards making things happen.

Anyhow, in the spirit of resolutions, here are my techie resolutions for 2007:

  1. Get a multi-exam technical certification
    I've been studying on & off for the MCAD but have always been "too busy" to get it and wasn't sure if it was even necessary. Well, I want to get it done. Maybe the MCAD, maybe MCPD, maybe something else. But some sort of Microsoft certification that involves more than one exam. It's possible that during the year I may do a non-Microsoft cert instead, but we'll see.
  2. Publish something technical
    It can be as simple as publishing an article on a site like 4GuysFromRolla, or maybe authoring a column for a printed magazine. Or even being involved in a book. But I think it'll be good for my career and my personal development to push myself and publish something. Sure, blogging takes some effort, but writing a focused, clear, and useful article is a new level of contribution.
  3. Speak somewhere
    I had a chance to speak at Portland's Code Camp 2006 this year. It was fun, a lot more work than I expected, and a great learning opportunity. I want to repeat that experience again in 2007.
  4. Learn about and/or get involved in something new technology-wise
    I want to branch out and get some experience and involvement in something substantial in the technology world. Maybe it's working more closely with GData, or deeper experience with mobile development, or using Ruby on Rails for a few projects. But I'd like to spend enough time with something that you might call a niche so that I can talk intelligently about it, help others with it, and/or specialize in it if I wanted to.
  5. Get a new computer
    I love my overclocked Athlon XP 2100+ dearly, but it's time to upgrade. Visual Studio is slow enough, and I'll be doing more and running more in the year ahead. I suppose I could scrap it all and go the Notepad + Mono route, but I really like strong IDEs. Plus who knows what new games are coming out in 2007. :)

That's all for now. There are other things I'd like to do next year, but they're smaller, less important (to me), and I don't want a huge list. You'll notice my resolutions are a bit on the generic side, partly because technology moves so quickly and I haven't 100% decided how I'd like to fulfill them yet.

Hopefully I've encouraged a few people to make some 2007 techie resolutions for themselves, and provided some ideas on some fun and useful things to resolve to. In case my list isn't for everyone's taste, here are some other good (IMO) techie resolutions that people might choose:

  • Update your resume
  • Start a blog and/or personal web site
  • If you're not ready to write articles, post some code samples up on CodeProject.
  • Attend a conference or trade show. See some presentations, talk to a few people, and hand out your business cards. Code Camps are good because they're informal and free, but anything that exposes you to people, ideas, and sunlight is good.
  • Join (or start!) a local users' group and attend some meetings. It's a great way to network with others, get ideas and feedback, and snarf some pizza.
  • Share your technical knowledge with others in need. Volunteer your services for a school, church, or non-profit. Tutor kids on computer skills. Teach or help out with a YMCA class.
  • Clean out your basement and donate all those older computers, monitors, cables, and whatnot to groups that can refurbish them and put them to use. Check out Microsoft's Computer Donation Tips page for ideas and places to donate. You'll be helping others and getting a tax writeoff at the same time.
  • Get involved with something technical outside of work, e.g. make your own mashup, contribute regularly to technical newsgroups, or help out with open source projects on SourceForge or CodePlex.
  • Implement a backup scheme so your pictures, documents, and code don't get lost in case something happens to your computer or home.
  • Be proactive about your career by learning a new system, using a new tool, or maybe even transitioning to a new position and/or company.
  • Replace your ugly, power-hungry, eye-hurting CRT monitor with a nice LCD. You can find a 19 incher on NewEgg for $200 or less, and believe me, you and the environment will be glad you did it.
December 28, 2006    Bookmark to Digg or other social bookmarking
#    Disclaimer  |  Comments [0]



 Monday, December 18, 2006
 
 

I saw this nice Code Smell summary at Berkeley thanks to Diederik Krols' anti-pattern blog. The Code Smell Summary (or maybe it's a cheat sheet) gives nice overviews of bad code practices, (briefly) explains why they're bad, and provides links to refactoring.com's illustrations and examples to demonstrate the problems and the cures.

Reviewing the code smell summary will help you become more aware of problem code in your own projects. Then if you really want feedback on your code, you can start using code analysis tools like FxCop or NDepend. :)

You can also read through some of the common refactorings as well as this list of database refactorings, although there's some sifting required to get to the real "a ha, that's a good idea!" stuff. I will say that the refactoring sites don't provide much explanation on why the ideas should be followed, presumably so that we'll be forced to buy the books.

Code | Tools
December 18, 2006    Bookmark to Digg or other social bookmarking
#    Disclaimer  |  Comments [0]



 Wednesday, December 13, 2006
 
 
The December 2006 CTP of Sandcastle, Microsoft's free .NET 2.0 documentation tool, is available. It has some new features and a bunch of fixes.
December 13, 2006    Bookmark to Digg or other social bookmarking
#    Disclaimer  |  Comments [0]



 
 

A service pack for MySQL Enterprise 5.0 was released, bringing the version number up to 5.0.30 and including changes like:

  • Bug Fix: InnoDB showed substandard performance with multiple queries running concurrently.
  • Bug Fix: InnoDB exhibited thread thrashing with more than 50 concurrent connections under an update-intensive workload
  • Bug Fix: Some queries that used MAX() and GROUP BY could incorrectly return an empty result

Plus a new beta version of MySQL 5.1 is out, with various fixes and enhancements.

December 13, 2006    Bookmark to Digg or other social bookmarking
#    Disclaimer  |  Comments [0]



 Friday, December 08, 2006
 
 

One of my clients has employees across the country at their clients' offices, and sometimes users at a given location report that their connection to the company web site is slow. To assist with troubleshooting, I usually have them first run a bandwidth speed test at SpeakEasy and/or SpeedTest.net. I have them choose a test server closest to where the company web site is hosted (in this case, Chicago). Several times in the past the speed tests would demonstrate a slow connection, and we'd then be able to start troubleshooting.

That doesn't always resolve the issue, though -- sometimes the speed tests would be fine, but access to the site would still be slow (again, only for those locations). I recently found another free traceroute tool to help diagnose connection issues between the user and the web site. I prefer web-based tools since oftentimes the user doesn't have rights to install desktop bandwidth monitoring tools.

I've thought about putting a speed test on our web server itself. You can actually host SpeedTest.net's speed test for $400/year, or Visualware's MySpeed speed test for $250/year.

I found one or two free tests that you can seemingly host, but they were java source code & required linux. I suppose making a very simple Flash-based speed test wouldn't be too hard -- download some uncompressible files (like ZIPs, JPGs, MP3s) from the web site and measure how long it took to download them, then display the results. For the upload test, generate some data, POST it to the server, and measure that upload time (either on the client and/or the server). Or I guess one could do the same thing using AJAX, too, maybe.

December 8, 2006    Bookmark to Digg or other social bookmarking
#    Disclaimer  |  Comments [0]