Search is really just part of navigation. In many cases information found by running a search routine can also be found by just browsing through the pages. Which serves the visitor best? … is that also what serves the mission best?

Search needs words (also phrases) for searching. When visitors compose their own phrases, will those phrase be effective in searching the website? If not, then search terms should be offered as items in drop-down lists or some similar selection interface.

Next there is the question of what will be searched. A Google-like search can theoretically see every word in the public space of the website. Will this work OK? … will many irrelevant items be returned? … or should that type of “free word” search be used, but restricted to parts of the space with relevant content?

Another approach uses either “free word” input or “selected word” input to search only prepared fields in the database. This allows the web administrators to help or control the search results, but requires maintaining those fields of search phrases.

Many choices and variations are possible. Least expensive is installing one of the free search routines, one that can be limited to just the one website, as Google can. It has quick setup, little maintenance, is familiar to nearly everyone, but in a small website it can be quite imprecise and may often return empty lists.

I recommend a careful discussion with your website’s Information Designer.

Medical data will proliferate exponentially in the coming years. There are many drivers and patterns. Of special interest to the US data industry is the proliferation generated by mobile sensory devices.

The devices themselves are proliferating. While away from medical facilities, one may wear or be attached to devices that sense pulse, blood pressure, body temperature, blood flow rates, and many of the other vital indictors. These data can be generated and stored at high rates. In the US, increasingly the data are stored in private medical practice networks. Imagine a small, 4,000-patient group fitted with a device or two, each generating data 24 hours per day.

In its “The World in 2012” edition the Economist points out the high value obtained from such data by Britain’s National Institute for Health and Clinical Excellence. They are able to closely monitor the benefits of new drugs and expensive treatments. There are studies showing the US value of such systems could be in the hundreds-of-billions range.

The data are accumulating, the value is becoming obvious, and the contracts to aggregate data from scattered systems will be many and huge. Nearly as demanding, will be the contracts to order the data so it may accessed by business intelligence systems.

Jon, Vicki, and Matt at the Ithaca 5&10 Race

One peril of software development is that there is too much sitting going on.  The mind and spirit get exercise, but not the bod.  We’ve experimented with knee stools, yoga balls, and stand-up desks at GORGES with mixed results.  Several of us walk or bicycle to work.

This fall our office manager Vicki has pushed a fitness challenge on the staff.  For those who volunteered (or were conscripted!), we divided up into three teams and are placing checkmarks on a master schedule when we exercise.  GORGES has sponsored trial memberships at the Finger Lakes Fitness Center for their six-week fall challenge.

In previous years we have taken the crew to the Hoffman Challenge Course at the Cornell Team & Leadership Center, and this year’s fitness challenge can certainly be labeled team-building.

The fall results aren’t in yet, but and unfortunately some of the fitness gains may be erased when we hold our gluttonous end-of-fitness-challenge party.

Wanting to be as unbiased as possible, I have researched online several times and offer these two third-party views:
http://www.bivingsreport.com/2007/wordpress-vs-drupal/
http://www.quis.com/2009/06/01/drupal-vs-wordpress

Both articles try to be unbiased, and I think they succeed. Neither writes that WordPress and Drupal are on the same plane. They both assign WordPress to the simplest of websites and Drupal to the next echelon. This matches our considerable experience. WordPress provides an elegantly ease-to-use CMS. It is the appropriate choice for lightly featured blogs and very simple websites.

Here’s the experience of someone who “loves” WordPress (the language needs editing):
http://kevinjohngallagher.com/2012/01/wordpress-has-left-the-building/

The Drupal community is on a different track. Drupal is a machine for making interactive websites – newspapers, magazines, large corporate websites, online stores. In the spectrum of technology, Drupal picks up where WordPress leaves off, and takes us toward standard web applications. When the project no longer fits “standard things you do on a website,” it is a web application that requires a web application framework. GORGES will in that case recommend the appropriate framework, maybe Ruby on Rails, Yii, or .NET.

It should also be noted, that when a client is engaging GORGES to perform setup, to propose designs, to guide the process and provide training, the distinctions having to do with ease of setup, theme decisions, and ease of use become inconsequential. GORGES shoulders those.

The differences between WordPress and Drupal are finally differences in capability. What interactive features does your website need now and how likely are you to want significant visitor interaction in the future? Is the site to be a one-time undertaking, or is it likely to grow thought time? If these are not issues, WordPress might be just right.

In this article, we will discuss approaches to creating charts on the web. Currently, there are two general approaches to creating charts on the web: Image-based versus Scalable Vector Graphics (SVG)-based. There are also Flash-based solutions but we cannot recommend them because Flash is not available on iPhones and iPads and the future of Flash-based solution is uncertain.

Image charts
Here, the server generates a static image (e.g., a JPEG) of the chart from the data and the image gets displayed in the browser. There are a plethora of server-side charting implementations to choose from — a noteworthy one is Google Image Charts: http://code.google.com/apis/chart/image. Since the chart is simply an image, there are no cross-browser issues and the look of the chart is also consistent across browsers. The chart can easily be exported for usage in presentation slides since the chart is just an image file. However, the disadvantage of this approach is that users cannot interact with the chart; they cannot click into a pie chart slice or hover over line graph points to better understand the data being presented. While image-based charts provide a consistent and reliable view of the data, this approach does not give your end users necessary usability needed to make effective use of the information.

SVG charts
Here, the rendering of the chart is strictly on the client browser: There is no server-side rendering of the chart. Data are passed into a JavaScript SVG library which renders the chart as SVG markup (or VML markup if the user is on Internet Explorer 6/7/8). The browser produces a chart from the resulting markup that is mostly consistent across browsers. (We have run into an edge case issue where labels on pie charts get cut-off in Internet Explorer.) Exporting the chart into a file for use in presentation slides is a little trickier — since SVG charts are derived from JavaScript libraries and you cannot create files using JavaScript (at least not easily or consistently across browsers). One possible solution is to post the serialized SVG output back to the server-side and convert into the desired target format (e.g., JPEG, PDF, etc.). These relatively minor issues are offset by the huge gain in chart interactivity. SVG charting libraries allows developers to attach mouse click and hover events to the charts, such that a user can drill down into a pie slice of a chart or hover over line graph points for a more comprehensive view of the data. The SVG charting libraries tend to be relatively easy to use for developers comfortable with JavaScript, relative to the server-side charting tools.

Choosing a solution
When choosing a charting solution, it is necessary to consider the following requirements:

• Does the chart have to be interactive? If the answer is a resounding yes, then SVG approaches are the only options.
• How important is exporting chart into other file format? If very important, then it may be worthwhile to look at image-based solutions or possibly dual solutions of both SVG and static images.
• Are we dealing with tens of thousands of data points? If yes, then it may be neccessary to sacrifice the interactivity of SVG charts for performance of static image charts.

SVG solutions
Below is a brief descriptive of three SVG libraries. This is by no means a comprehensive list.

• gRaphael: http://g.raphaeljs.com
• Only completely free solution of the three.
• Not as mature the others and poorly documented.
• Programming somewhat easy.
• Fewer eye candy.
• Bottom-line: Check back in 6 months; the library is improving rapidly.
• Google Chart Tools: http://code.google.com/apis/chart
• Does not cost money but source code is not available and hard dependency on Google’s server.
• Mature and well-documented.
• Programming not as easy but powerful.
• Better eye candy — see Geographic chart.
• Bottom-line: Good solution but the charts and data security are heavily dependant on Google’s server.
• Highcharts: http://www.highcharts.com
• Costs money (couple of hundreds) but open source.
• Mature; Good documentation.
• Programming is easy.
• Best eye candy — charts will “pop” to your users.
• Bottom-line: Best overall general-purpose charting solution.

There are legitimate reasons to leave them in test/staging code, if you’re still working out some details.

So I wrote this little library as a replacement.

It doesn’t blow up when the console is not available, adds chainable log() and warn() methods to jQuery selectors, and improves a bit on the display in FF and IE9.

Tested and working nicely in FF, IE9 and Chrome.

I realize this isn’t a groundbreaking idea – but I looked at a couple of existing libraries that do something similar, and nothing really seemed to work well in IE.

Also, this kind of thing should be small – this script compresses to less than 0.5 KB.

On Friday afternoon the event started with brainstorming sessions, and presentations of possible startup ideas were made that evening.  Votes were cast and teams formed around the half-dozen or so leading ideas.  Each team had students with different roles for the concept development, business modeling, and actual programming.

Fueled by caffeine and sugar, the teams worked all weekend in preparation for Sunday evening’s final pitch.  For GORGES’ role, Don Ellis and I were involved at the three mentoring sessions.  To the best we could, we asked questions and offered advice based on our own startup experiences.

On Friday evening the teams presented their ideas and working prototypes to a panel.  The presentations were well-attended, and I would not be surprised if a few of these teams evolved into real startup companies.

As for the actual ideas, most involved using mobile smartphones.  That is a clear indication of where future opportunities lie, and I’m glad we have cultivated and matured our mobile development talent at GORGES.

It was great to see such enthusiasm during the weekend, as well as impressive programming and business talent.  Kudos to Sohan and his team for putting together a great event.

Usually developers work directly on their workstations or laptops, and a development environment has both web and database services running similar to a production server. Ideally a development environment should have the same versions of services as the production server, for example PHP 5.2 or Ruby 1.9.  On more than one occasion I have been bitten by writing MySQL 4.3 or 5 code, but the production server has an older version of MySQL without sub-query support so the queries had to be rewritten.

Usually these development services are customized for development, for example the database does not have to be hardware-optimized and the web service can have debugging tools enabled.  I prefer to turn on all warning messages, so any identified problems that are not severe enough to halt page serving will be shown either in a log file or onscreen.

Just as important with having a staging server is to have clean and well-structured publishing scripts.  If you are relying on a manual process to upload files using FTP, then it is possible to skip an updated file by mistake.  Publishing scripts come in all sorts of flavors and approaches – we have both “pull” methods that use server-side scripts, and “push” scripts that execute on the developer’s computer and automatically upload files to the server.  The push scripts are built on Capistrano, which although it is based on ruby we sometimes use at Gorges for non-ruby websites.

We routinely protect our staging servers from prying eyes and search engines by using HTAuth username and passwords.  Once a website is scanned by a Google, Bing, or other web crawler then it is out of your control.

Having a staging server doesn’t mean much unless it is actually used to test new features and look for bugs.  Quality assurance is important, and I have yet to meet a developer that produces bug-free code or see a unit testing system that covers 100% of a web application feature set.

Not covered in this post is the issue of database migrations between developer environment and a staging server, and also from a staging server to a production machine.  These can be tricky, but as with all challenges the proper planning will guide you to the best solution.

After the application or update goes live to the production server most staging servers are continued as “sand boxes” to support additional updates and testing.

Finding straightforward explanation of how to immediately dive in proved to be a bit painful – most of the tutorials I found seemed to be aimed towards clients or casual Facebook users rather than developers. I thought I would compile the information I found useful in quickly making custom tabs for Facebook pages.

First of all, even though they still use the term tab, what we are talking about are the links in the left column that fall under Wall.  A standard first  custom tab to add is a Welcome tab.

I originally tried using an existing app (Static HTML frame tabs) which worked fine, but had two major disadvantages.  One was that you could not assign a custom icon, and the second that it could only be used to create one link.  This could be handy for a quick and easy custom welcome page, but most likely a client is going to want more than one custom tab.

I won’t cover signing up as a developer, but basically it involves creating a Facebook account and being assigned as an admin to an existing business page, or creating your own.  You will also need to be confirmed via a text to your mobile phone or by entering a credit card.

After you’ve done this, you can head on over to http://developers.facebook.com, and hit the Apps link, and then the + Create New App button:

Create a name for the app:

This will create an app with an app ID (which you will need later).

For now, you can just upload a 16×16 icon that you would like to appear to the left of the link on your page.

Now, click the On Facebook link in the left column.

Enter the Tab Name (This is the name of the link as it will appear on your page) and the Tab Url.

The Tab Url is a link to a file hosted somewhere else that will be placed in the iframe (more on constructing this later)

After saving, click View App Profile Page in the left column

Now you can click Add to My Page , and then select the page (for which you are already an admin) that you wish to add it to.

Now, if you navigate to the page you’ve added it to, you will see it as a tab in the left column:

Hit the Edit button below the tabs to rearrange the tabs, but note that Wall and Info will always come first.

To make this new tab the default landing page of your site, click Edit Info at the top of your page.

Now click Manage Permissions and then choose the Default Landing Tab from the dropdown.  Note that fans and admins of the page will always be directed to the wall – this default landing page only applies to anonymous users or non-fans.

Finally, a note on creating your content for the iframe. I initially ran into some problems with scrollbars appearing both vertically and horizontally in the frame – the solution was to include two Facebook scripts and apply a little bit of css, all of which you can see in the basic template below. You’ll need to modify the height, add your content, and also include your app id in the bottom script.

<!DOCTYPE html><html>

<head>

<title></title>

<script type=”text/javascript”>window.fbAsyncInit = function() {FB.Canvas.setSize();}function sizeChangeCallback() {FB.Canvas.setSize();}</script>

</head>

<body style=”width:520px;overflow:hidden;”>

<!– Modify height if necessary –>

<div style=”width:520px;height:1000px;overflow:hidden;”>

<!–Your Content Here –>

</div>

<div id=”fb-root”></div>

<script src=”http://connect.facebook.net/en_US/all.js”></script>

<script>

FB.init({

// CHANGE THIS TO YOUR APP ID

appId : ’123456789′,

status : true,

cookie : true,

xfbml : true

});

</script>

</body>

</html>

That’s all you need to do.

GORGES was well prepared to participate in this discussion, as we are contributing to this job growth in upstate NY, which has lost over 100,000 manufacturing jobs in the last five years.

Don introduced GORGES and pointed out a key challenge we face in our continued growth.  Many other business representatives delivered their input and suggestions as well.  The Senator was focused and well-spoken, and clearly motivated to learn from this elite group of individuals so that she can advance legislation and reduce barriers to help these growing businesses thrive and contribute jobs and economic prosperity to the region.