Brad Treat gave a talk last night about his entrepreneurial philosophy, and also anecdotal stories from the multiple startup companies he’s been involved with.

Thank for sharing, Brad, and good luck to all the PopShop entrepreneurs.  There are several more events scheduled this week, including some success stories from the Cornell 3-Day Startup event in February.

Building a website to comply with Section 508 or WCAG accessibility standards can mean meeting a number of specific technical requirements.  To assist in building websites that meet these standards, GORGES has found a number of tools that ease the development process.

Total Validator Tool will validate the markup of a web page against Section 508 and WCAG standards.  Getting the markup to validate to these standards helps prepare the website for visitors using screen reader software. Total Validator Tool generates easy-to-follow reports which detail where the markup of a page does not meet the accessibility standards.  From this report, developers can easily see what changes are necessary.

However, once the website markup meets the appropriate standards, there are other aspects of the standards that are beyond what the Total Validator Tool is designed to detect.  These include considerations for visitors with color blindness and preparing any video used on the website for visitors who may be blind or deaf.

Vischeck is a service that will simulate colorblind vision.  Images or screenshots of a website can be uploaded and processed for free at the Vischeck website.  This can give a general sense of how a website may look to those with a form of color blindness.

To ensure a website is usable by those who are colorblind, checking the contrast between foreground and background colors is essential.  The accessibility standards indicate what contrast ratios are necessary.  The WebAIM Color Contrast Checker will provide a ratio based on provided colors while the service Check My Colours will analyze the colors used on an entire site.

Universal Subtitles is a service for adding captions (and translations) to embedded video.  This service is compatible with many popular video hosting services and video players.

JW Player is good option for embedded video that is self-hosted.  It can meet some of the stricter versions of the accessibility standards using the optional Captions plugin and Audio Description plugin.  This includes not only closed captions but closed audio descriptions.  A closed audio description is an additional audio track that may sometimes be needed to describe the video scene to visitors who are blind.

For an overview of making video accessible, a good document can be found at the JW Player website titled “Making Video Accessible.”

Commonly used screen readers include JAWS and Window-Eyes.  For testing with a screen reader, an article on the Yahoo Developer Network suggests using a free and open source screen reader called NVDA.  The article “Easy Accessibility Testing with the NVDA Screen Reader” states:

“NVDA for Windows is one of several screen reader programs available on the market today. NVDA is free and open source. It is very strict in how it treats web pages and thus can serve as a perfect testing tool.”

By utilizing these tools, many of the challenges of meeting accessibility standards can be more easily overcome, and your website will become usable by a larger audience.

Websites and apps are not commodities and the purchasing of them is not a one-night-stand. Websites and apps are born into dynamic environments. Their full value is realized when they are maintained current with those environments. The developer relationship established during the initial development is part of the purchased value. Economies accrue when a structured relationship is maintained.

A Maintenance Agreement provides the budget to prevent obsolescence. The sad news is that a new website or app is becoming obsolete even as it is built. All three sectors of the technology advance rapidly.

• New display and interaction devices replace the old at increasing rates.
• There is daily industry news about greater power in databases and middleware.
• Methods-of-use, ways of thinking about these technologies, sprint into our lives.

The users of any valuable website or app will chafe immediately when it does not take advantage of this or that new device, or some new way of searching, or some social opportunity. Staying atop these concerns is the noble use of a maintenance agreement.

A Maintenance Agreement budget also should be provided for installing important updates to the underlying software. The price should be small, maybe $250 per event, maybe two or three events per year. Security updates in particular must be done.

A Maintenance Agreement provides a management structure for all the above. There is a prioritized wish list, a clear line of communication, and a non-intrusive billing arrangement.

The Maintenance Agreement budget is not for hosting the app and ensuring its connectivity. These services are budgeted under Hosting Agreements.

GORGES would be embarrassed if Maintenance Agreement budgets were spent mostly on fixing the app. In some cases this is appropriate use, but there should be very little of this. Websites and apps are warranted for thirty days after going live and after major upgrades. Clients should test the app thoroughly before and during that period to take advantage of the warranty.

The best websites and apps pay their own way. Allocating a portion of the return for maintenance extends their lives and empowers their constituencies.

OrientDB is nearing version 1.0, and it has a native HTTP/JSON interface – it supports classes, inheritance and all kinds of relationships, all the things we try to simulate with object-relational mappers when building a domain-model, which makes me wonder… why use an ORM at all?

If you’re going to do all your data-binding on the client-side, and if a graph database can natively represent your domain-model without a line of code, why struggle to achieve the same thing with server-side code and object-relational mapping?

You’d only need controllers/actions for actual business-operations. You could probably implement a thin “proxy” for operations like updates and deletes, access control and user identity, etc… You would never need to render a template, generate tables or forms or parse a form-post or implement tedious CRUD operations on the server-side.

It all sounds dreamy, and I can see this working out great for applications.

But what about SEO? The internet lives and breathes HTML. So it seems it’s not an approach that will work for public-facing pages.

Any thoughts?

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.