I've been searching for about six months for a decent way to handle web searching inInfoMesa. We've always had the idea that searching the web and persisting the results in InfoMesa was core to the project. But the ability to show the thumbnails of these results has eluded us...until now!

In November, I researched various service players including Alexa Thumbnails (from Amazon) and PageGlimpse. Alexa turned out to be a bad choice - too slow, poor service, poor support, and poor turnaround on thumbs that they didn't have cached. PageGlimpse on the other hand, was a pleasure to work with from the beginning.

Here's a shot of the InfoMesa persisting 3 web searches with 10 results each.

You'll notice some look the same. PageGlimpse attempts to use it's cache, but failing that returns a placeholder. True to form, in a few hours the images are there and the placeholders are replaced with beautiful miniaturized forms of the web page. Even Flash sites are returned.

PageGlimpse uses REST, which I had never used before, but found really easy and cool to use. Much better than adding a Web Service Reference and more applicable to the Composite Model that InfoMesa Phase 3 is headed into.

Get your Developer Key at PageGlimpse first!

Here is some sample code for generating web thumbnails using the PageGlimpse Service:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Data;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Imaging;
using System.Windows.Navigation;
using System.Windows.Shapes;
using System.Net;
using System.IO;
using System.IO.Compression;

namespace Thumbnails
{
    /// <summary>
    /// Interaction logic for Window1.xaml
    /// </summary>
    public partial class Window1 : Window
    {
        public Window1()
        {
            InitializeComponent();
        }

        private void button1_Click(object sender, RoutedEventArgs e)
        {
            ShowThumbnail(@"http://www.pdb.org/");
        }

        private void button2_Click(object sender, RoutedEventArgs e)
        {
            ShowThumbnail(@"http://www.skywalkersound.com/");
        }  

        private void ShowThumbnail(string website)
        {
            string url = String.Format("http://images.pageglimpse.com/v1/thumbnails?url={0}&size=large&devkey=<PG_DEV_KEY>, website);

            BitmapImage bi = new BitmapImage();
            bi.CacheOption = BitmapCacheOption.OnLoad;
            // BitmapImage.UriSource must be in a BeginInit/EndInit block.
            bi.BeginInit();
            bi.UriSource = new Uri(url);
            bi.EndInit();
            // Set the image source.
            image1.Source = (ImageSource)bi;       
        }

    }

}

PageGlimpse supports three sizes, plus custom sizes on request...

Small: 150x108, ~4kb

Medium: 280x202, ~11kb

Large: 430x310, ~25kb

Additionally, sometimes a compression scheme called GZIP is used (not for PageGlimpse, but for other image sources) - it's hardly relevant here, but I thought it made sense to post it...I searched a long time to find it...

private void REST_Call()
        {
            string url;
            url = "http://images.pageglimpse.com/v1/thumbnails?url=http://www.google.com/&size=large&devkey=<PG_DEV_KEY>";
            // Create the web request
            // PageGlimpse: fa692e01ce5e95594e9d9174e7ffadb9
            // UID/PWD

            HttpWebRequest request = WebRequest.Create(url) as HttpWebRequest;

            // Get response
            using (HttpWebResponse response = request.GetResponse() as HttpWebResponse)
            {
                //Stream getresponse = response.GetResponseStream();

                // Handle GZIP Compression...

                Stream responseStream = responseStream = response.GetResponseStream();
                if (response.ContentEncoding.ToLower().Contains("gzip"))
                    responseStream = new GZipStream(responseStream, CompressionMode.Decompress);
                else if (response.ContentEncoding.ToLower().Contains("deflate"))
                    responseStream = new DeflateStream(responseStream, CompressionMode.Decompress);

                BitmapImage bitmap = new BitmapImage();

                bitmap.BeginInit();
                bitmap.StreamSource = (System.IO.Stream)responseStream;

                bitmap.CacheOption = BitmapCacheOption.OnLoad;

                // IgnoreColorProfile solves FileFormatExceptions with JPEGs created by IJG.

                bitmap.CreateOptions = BitmapCreateOptions.IgnoreColorProfile;

                bitmap.DecodePixelWidth = 430; //430 x 310
                bitmap.DecodePixelHeight = 310;
                bitmap.EndInit();

                response.Close();
                responseStream.Close();
                WebThumbnail.Source = bitmap;
               // bitmap = null;
            }
        }

As 2008 winds down it's time to reflect on where the InfoMesa initiative has come from, where it is now, and where we wish to take it. Over the last year I have talked with literally hundreds of scientists and been all over the central and eastern United States talking with Pharma and Life Science companies. I've met amazing people and received lots of great comments about InfoMesa.

When we started this in September of last year we didn't know if a lot of things that people wanted to do were possible. The first phase was simply to build a technology demonstrator using C# and Windows Presentation Foundation (WPF). We tested for two things. First, could we host many different types of visualization tools and work and organize them intuitively. The Whiteboard, Skiff (underlying parental model for all elements) and lasso capabilities (grouping and arranging) came from this first test which we called Phase One. Secondly, what kind of visual structure and "language" would be needed to handle something of this sophistication.

InfoMesa circa November, 2007

Phase 2

Phase two helped us to formalize the "language" into areas that were predictable. We learned that Whiteboards should be arranged in a higher mechanism (a room) and that Whiteboards should allow people to push and pull elements between them and travel between the Whiteboards easily. We laid out a predictable viewing mechanism for looking at Whiteboards Spatially, Chronologically and from a Commonality perspective, while also allowing tagging and searching at an single element level. For me, personally, the ability to persist the changes and store them easily was the most important milestone of InfoMesa Phase Two. We also did work on Annotations in the fabric of the application--Understanding what was needed to hook two and three-dimensional items together and how to persist these changes.

InfoMesa circa November, 2008

So, that brings us to Phase Three. Over the last month, I've been traveling to various customers and trying to understand where we go next. I do believe that we have accomplished much of what we looked to do with Phase Two. Storage brings up a lot of questions with customers. How do I scale this up? How do I share across the globe? How many databases do we need? If I use one, how "chatty" is InfoMesa? ...AND THE MOST CRITICAL...how do I share with partners that are not in my organization? AND THAT, of course, BRINGS US TO SECURITY!

Storage

Currently we persist the InfoMesa changes into a Microsoft Access Jet Database. While embarrassing, we did this to allow for ease of portability and to prove what we needed "sophistication-wise" to store XML. When we start talking about sharing information, Access is not the right platform - not by a long shot. There are plenty of directions to go. The easiest path is to move to SQL Server 2005/2008. With backup, replication, web service stubs, Analysis Services, Integration Services (ETL) and Reporting Services as well as integration with Active Directory this seems like a good path forward. Then, there's the new kid on the block: SQL Server Data Services. A cloud-service DB that is similar to Google BigTable and Amazon SimpleDB. This allows sharing and scale at a massive level and it pushes security to the forefront of the conversation.

Security

Security is a huge deal for InfoMesa and we've put it off long enough. Now that we have proven that we can host these things side by side, store them and reload them, we need to prove we can secure them, both individually and in bulk. Each Whiteboard and Room can be secured, but so much each element. In the photo above, I might wish for a researcher at Duke University to work on the Tumor image and the video clip, but completely hide the molecule element (not disable----hide!). Most every Pharma/Life Science company is secured by Active Directory for authentication and authorization to on-premises assets. Many academic institutes don't have such a formalized mechanism - and many use outside authentication mechanisms like Open ID. Microsoft is diligently working on federating security models and we can ride that wave, it's just important to understand the differences between enterprise and academia in this regard.

Collaboration

Collaboration has been mentioned more than once. Whiteboards, in and of themselves are interactive animals, so we need to understand what it's like to work with multiple people on the same board. How to invite them in, how to group things together and how to annotate and journal on multiple levels.

Composite Applications

The final item, and this is big...is maintainability of the framework. Right now, in order to add new elements (Tools) to the InfoMesa, we need to code up a class and recompile the application. This won't work in the real world. People will be developing components in China and India, while the US is also adding items. We need a composite structure that both allows individual items to be developed away from the fabric, while also adhering stylistically. This will also allow elements to talk back and forth, informing one another of events and common items (brushing a molecular model will possible inform a grid or a gene expression map of the same element).

Composite Application Guidance for WPF (Composite WPF for short) is a set of libraries, documentation, and sample code from Microsoft patterns & practices that helps you to build clean, maintainable applications. This article shows you what the Composite WPF provides and how to use it to build your WPF applications. The first question you may be asking yourself is "What's a composite application?" In simple terms, a composite application is composed of multiple loosely-coupled parts. WPF itself is built on the concept of composition. You compose your UI out of granular UIElements, forming a whole that users see as a Window or Page on their screens. Composite WPF is more abstract, focusing specifically on how you compose the code artifacts that contain both the UI definitions and the logic code that supports the UI presentation.

Composite WPF helps us accomplish these goals by providing the following features:

• Modular loading: You can decompose your application into multiple loosely-coupled modules that get dynamically loaded at runtime.
• UI composition: You can dynamically compose portions of your UI out of loosely-coupled views, and you can follow UI design patterns to keep the logic code decoupled from the UI definition.
• Commands: You can use a commanding infrastructure that overcomes limitations in WPF Routed Commands and that allows command handlers to be decoupled from the UI itself.
• Loosely-coupled Pub/Sub events: You can publish and subscribe to strongly-typed events from logic code scattered across your application without any direct references between publishers and subscribers. You also have control over what thread the event notifications are made on, and have the ability to filter notifications based on the contents of the event data payload.

We will continue to use Phase Two code base (although we will fork it) for visualization and UI additions and testing, but the underlying fabric will be redone to address composite apps, storage and security, which will enable collaboration.

Additionally, we will be integrating deeper with Sharepoint and Microsoft Office as well as doing some Semantic Tagging work.

2009 promises to be interesting!