Archive for the ‘Technology’ Category

Client-side Data Binding

Monday, February 6th, 2012

Anybody give much thought to client-side data-binding these days?

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

Rasmus Schultz has worked for web development companies, advertising agencies and a music software company during his extensive development career. His main strengths are software development and database design. Rasmus has more than a decade of experience with many development platforms, languages and standards.

Website Search Strategies

Thursday, February 2nd, 2012

Search strategies should relate to a website’s mission and message. They also need to respond to the anticipated user skills and preferences – optimal search strategies on a website for scientist or engineers would be quite different from those for the general public.

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 Proliferation

Thursday, January 26th, 2012

Medical Data Proliferation – One Pattern, One Value, and One Prediction

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.

Choosing Web Chart Technologies

Friday, December 9th, 2011

Web-based charting has emerged as another great use of the browser. Traditionally, business analysts were the ones crunching numbers on spreadsheet to build charts. The spreadsheet would be e-mail as a file attachment. This process of compiling numbers and chart building could take hours. There is the saying that once information is on paper, it is already outdated. It will not be long before the saying becomes: Once information is in an office file document, it is already outdated. As a result, the web is quickly becoming the preferred platform for data charting and analysis.

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.

jQuery DOM shortcuts

Monday, June 13th, 2011

Working daily with jQuery, at GORGES I frequently need to construct little document snippets and forms on the fly. Today I came up with a quick little meta-programming “hack” that makes this very easy and fast.

Most people simply do something along the lines of this:

$('body').append('<h1>Hello, World</h1>');

jQuery injects the HTML string into the DOM, and all is well.

But sometimes you need to inject more structured content, or even entire forms – what I typically do is something along the lines of this:

jQuery('body').append(
  $('<div/>').append(
    $('<div/>').text('Hi there'),
    $('<p/>').text('How do you do?')
  )
);

With all the parentheses, angle brackets and repetitive calls to append(), this doesn’t exactly look nice.

Recognizing the repetitive construction of elements, followed by calls to append, what if we had a set of tiny functions that would do both in one simple operation? I decided to give it a shot, and here’s what it looks like:

jQuery('body').append(
  $div(
    $h2('Do you love it?'),
    $form(
      $div('Sign here:', $text()),
      $div($label($checkbox('yes'), 'I love it!')),
      $ul(
        $li($radio('1'), 'Option One'),
        $li($radio('2'), 'Option Two'),
        $li($radio('3'), 'Option Three')
      ),
      $submit('I submit!')
    )
  )
);

The functions prefixed with the $-sign create the elements, and pass down any arguments to the append() method.

The input element methods, such as $radio and $submit are a bit different – they create input elements, set the type-attribute, and if you pass them an argument, they apply that as the value-attribute on the element. (input elements can’t have child-elements, so this doesn’t get in the way of anything.)

You can see a working example and source code here.

Because JavaScript is a highly dynamic language, I didn’t need to write each of these $-functions by hand – with just 13 lines of JavaScript, applying a simple meta-programming technique, all of the functions are automatically generated.

Finally, it’s worth noting that something like $('<div/>') actually results in a string of HTML being parsed and then inserted into the browser. My handy little DOM-helpers avoid the parser – they access the DOM and create HTML elements directly, which means they execute around 10 times faster compared to the first example.

Update

One of my GORGES colleagues pointed out the fact that I had no convenient way to apply attributes to the created elements – if you don’t like the repetitive calls to attr(), try this updated version, which provides a simplified way to apply attributes quickly. This takes a bit more code, but I suspect he’s now porting this to CoffeeScript

Rasmus Schultz has worked for web development companies, advertising agencies and a music software company during his extensive development career. His main strengths are software development and database design. Rasmus has more than a decade of experience with many development platforms, languages and standards.

Transition operating systems

Monday, May 16th, 2011

Modern mobile operating systems are all the hype, and we’re feeling it here at GORGES – clients are becoming increasingly aware of the importance of mobile technology.

The major contenders when it comes to mobile operating systems are Android, iOS (more commonly known as iPhone, iPad and iPod), and Windows Phone 7 – all fantastic mobile operating systems, it is hard to even begin to compare them to their predecessors.

But why were we suddenly (these past few years) imbued with these brilliant new OS’es?

The answer of course is advances in hardware – lower cost, more computation power, high resolution displays and multi-touch, more storage, faster wireless networks, longer battery life… and on top of all that, advances in nanotechnology has made everything smaller and lighter, too.

My point with this little article, is to share with you an observation that has surfaced in a few of my conversations lately: that these new mobile operating systems are part of a transition towards “real” operating systems running on mobile devices. In fact, I’ve taken to referring to them as “transition operating systems” myself.

The evolution of mobile hardware does not cease. What made these new OS’es possible, is the fact that mobile devices are now almost as fast as “real” computers – and that same progress will put an end to them, too.

Soon, mobile devices will be fast enough to run “real” operating systems – and when that time comes, why would you want a dedicated mobile OS, or even a mobile device dedicated to wireless communications, such as your phone? If you could run a real Windows, OSX or Linux OS on your device, why wouldn’t you? At least two of the major players in mobile hardware, NVidia and QualComm, are currently racing to bring quad-core processors to market this year, so it may be more imminent than you think.

I suspect certain companies, such as Apple, are already having the same realization – it was recently rumored that certain features are being migrated from iOS to OSX. My guess is, they’re getting ready to add support for iOS apps to OSX, with the intent of running OSX on a mobile device in the no-too-distant future.

This is all speculation, of course – and either way, it doesn’t diminish the value of the mobile “transition” operating systems, which paved the way for new advances in user interface / user experience development, and have set new standards for human-machine interfaces overall.

And it certainly doesn’t mean that you should hold out on your business ideas – waiting for real operating systems to hit your cell phones – the new mobile platforms are already embedded in our lives, and they are inevitably here to stay, in some form or another.

Rasmus Schultz has worked for web development companies, advertising agencies and a music software company during his extensive development career. His main strengths are software development and database design. Rasmus has more than a decade of experience with many development platforms, languages and standards.
©2012 GORGES - All rights reserved
where programming meets design and lives happily ever after