Silverlight 4 PivotViewer…I like it…A lot…

There aren’t many controls that I see that make me sit up and think “wow”, however this really is one of those. For a while now I have been coming up with new ways in which to allow users of our workFile ECM product to access massive amounts of data visually, allowing the user to search through them in a graphical way that is both intuitive, but more importantly in a fashion that is usable rather than just looks pretty. We have had quite a lot of success with this, however in certain areas our solution just isn’t perfect, and for these areas we revert to more traditional methods of understanding / navigating data. The main issue is usually the potential amount of data the user may have to look through…

Let’s have an example. A while back I was asked to consult for a company that were looking at a solution that needed to look through vast amounts of pictures and graphics. The vendor had a very visual solution; it looked great and performed ok, for small sets of data. It involved using nicely animated thumbnails of data, which the user could then navigate, very similar to the standard tree view with details pane. However, the problem arises when your node could contain hundreds of thousands of images (which the customer did have). While the demo looked great and all the representatives from the client thought it would do the job perfectly I had to speak up and ask just how it would cope with say 500,000 images in a single node….. The vendor looked a little shocked and said “you would navigate in the same way or break the node down into several other nodes”…The client looked fine, however again I had to point out that scrolling up and down searching for a single image in 500,000 or popping into every sub node to find my image would take a hell of a long time. It was at this point that the vendor and the client both realised that this solution wasn’t going to work for them….Now this may seem obvious, but the issue with cracking graphical interfaces in this fashion is that, while they work great on smallish subsets of data, they really do fall down to massive vast amounts of information (you can’t beat a good text based search can you…..or can you…)

This morning I decided to finally look at the PivotViewer with Silverlight 4, and, I was very impressed. I have to say I like it a lot…All of a sudden I have a tool that can give me just what I have been looking for (without anyone here having to spend a long time coding).

What is PivotViewer

Basically it is a Silverlight 4 based control that allows you to graphically represent collections of data. You can filter and sort this data quickly and move between different views of your collection allowing users to quickly identify just what they are looking for, or perhaps trends in data for example…

What could we use it for?

Well there are many things it could be used for. A couple quickly spring to mind. Imagine a way of quickly and accurately reviewing your quarterly sales in a graphical format. Then imagine being able to break that data down (using the same graphical format) into each month, then week, then day. Or perhaps you want to compare cars based on fuel economy, price, and number of seats. As a user, you can filter and re-filter all this information graphically so you can quickly and intuitively find what you are looking for…

There are many uses for this particular tool, and it could indeed lead to RIAs that deliver a completely new way of providing us with data and even navigation…

Interested?

Well if you are interested, have a look at http://www.silverlight.net/learn/pivotviewer/

HTML 5 – It’s not the end of internet plug-ins

I have posted a number of times now about HTML5 and my concerns that people see it as a complete replacement for internet plug-in such as Silverlight and Flash, allowing RIAs to be delivered in pure HTML 5. One of the main people who keep going on about HTML 5 is Steve Jobs (though I think a lot of this is trying to convince the users of iPhones and iPads that Flash has a short life ahead). However, it seems that more and more people are sharing my opinion that HTML 5 will not kill of Flash and Silverlight, and that its adoption is a hell of a long way off in general…A recent report and article from Forrester illustrates this…

HTML 5 traction and buzz….

There is for sure a lot of buzz around HTML 5 in the past couple of months, least not because of Jobs, but also because Google has recently open-sourced its VP8 video codex. To date, abilities and licensing issues surrounding such video converters have been one of the sticking points for beta HTML 5, however this is not the only issue. Though there is a lot of internet buzz, it seems that adoption of HTML 5 is a long long way off, with browsers only supporting small fragments of HTML 5 currently. It seems that for wide spread adoption, as users we will be waiting until 2020 or sometime around then…That’s not exactly close is it…Its again another reason why I am not at all “hyped up” about HTML 5, it’s just so far off….

So while HTML 5 is a long way off, just think how much traction Flash and Silverlight will gain in this period. Silverlight is the new boy on the block, but has already around 60% adoption across all machines. That’s rather impressive, all this while HTML 5 is in beta releases and going through a lot of, development pains and issues shall we say…

There is also the issue of cross browser issues. Just like HTML 4, HTML 5 will suffer at the hands of different browsers. The author of the Forest report (Hammond) stated “Until you get consistent behaviour the question will be why you would use HTML 5 when it actually creates more challenges than it solves from a testing and deployment perspective.” I have to say, this has always been an issue with HTML in general, especially when delivering internet applications, and it is one that won’t go away for HTML 5…Though HTML 5 is supposed to be intended as an enterprise-class product, the reality is that the architecture of HTML 5 with the browser has a number of issues and draw backs, even when talking to web services. Though the aim is for HTML 5 to allow easier building of “applications” the fact is that HTML and that side of the web architecture was never designed with this in mind….

Test once…You are all done…

Ahh, well this is not the case is it with HTML. Unfortunately you will need to perform tests on all the browsers out there, and no doubt, place “HTML fixes, CSS fixes and JavaScript fixes” into your application depending on what browser is running it. This does make life a lot harder for testing and development, oh, and of course ongoing support. However, this problem is just not there for Flash and Silverlight, because their architecture is completely different and in many ways separate from the browser and the web in general, indeed you can run Silverlight out of the browser fine…

Hammonds recent report – titled “Does HTML 5 Herald the end of RIA Plug-Ins? Not Really” – found that application delivery through RIA amongst businesses rose to 34% in 2009, up from 26% in 2008. This illustrates the increase use of RIAs amongst businesses, especially with technologies such as Silverlight develop further, all this while HTML 5 is still in its draft phase…

For traditional website material, you could still use HTML and HTML 5 if you wish, however for complex functions and applications, I would always recommend the use of Silverlight, there are just so many hurdles you negate while being able to use a technology that isn’t restricted by the browser web architecture.

Open aspect of HTML 5

So many people claim they love the idea that HTML 5 is “open”. And there are some good arguments made for this, however I have yet to see one example where these arguments are valid. Especially arguments that users may have to pay for Flash or Silverlight use, that you can become restricted to what browsers you can use, or that you are dependent on them for your support…I don’t see an issue or potential issue with any of these arguments, they are just created so people try to feel more safe with an “open” technology controlled by many rather than a single company…

However, this open aspect of HTML 5 may also work against its progress and adoption, especially as open standards are very slow to develop. HTML 5 has been in development for a decade now, and though early candidate releases are recommended for 2012/13, it is a while yet before we see HTML 5 as the standard version of HTML being used. On top of that, cross browser issues and W3C adoption is even further off…

Architecture…

RIAs require processing on the client, or at least they should do. Users expect “thick client” performance and usability in an RIA and on top of that, access to hardware components, such as storage, web cams, other applications running on the client etc etc. The architecture behind the web and HTML jsut doesn’t allow this. Though HTML 5 will bring us a richer web, with easier video playback, website animations and improved usability (a little like Ajax has done), it will always be behind Silverlight for example, that can take advantage of hardware on the client, keyboard interactivity, integration with other applications and the ability to work in a “disconnected state” from the internet….

My own view on the use of HTML 5 in the future…

It simple, for typical web content, HTML 5 will provide a greater level of interactivity, animation and improved user experience. It will no doubt be used for “simpler” RIAs, however its adoption as a serious RIA for businesses is plain fantasy. RIAs need to deliver more, and therefore organisations will continue to look to plug-ins, especially Silverlight more and more. I also believe that websites available to the general public will also have more aspects delivered in Silverlight, even once HTML 5 has gained traction, simply because Silverlight can deliver a better end user experience without many of the hassles associated with web development and HTML, CSS and JavaScript across multiple browsers…..

RIA is for your Intranet

Silverlight delivers RIA

Many corporate intranets require typical web functionality, but also they are often used to deliver application type solutions to the user without the hassle of maintaining any installations on the client PC. So what’s my point….Well my point is that web applications provide great value to administrators of systems, but they really do detract from a user’s experience. So how do we make what should / could be a thick client application, work well within an intranet environment?

User Experience

We all have used web based applications, some great some very poor. However, with almost all of them they are delivered in an old fashioned way. For example, a user makes a request to the page, something happens on the server, the page is recreated at the server then sent back to the client updated in its new state….Great. However this can take time, which isn’t always great, but more importantly it can become limiting and frustrating to users. You also have to think that changes to the look of a page still have to be processed and completed on the server. At the end of the day, standard web applications still feel, well, a little “clunky”, no matter how much fancy Javascript you can write…

Often because of this, users don’t give great feedback on the intranet itself, which is wrong; rather they should be giving negative feedback on that particular application / service delivered through the intranet (there is quite a big difference).

An improvement…

Intranet applications that take advantage of AJAX do deliver a far greater experience – AJAX has ensured we are moving in the right direction, ensuring you don’t always have to wait for a page to be submitted and then returned – rather the page has a “conversation” with the server. This has improved the user experience greatly and has removed much of the “clunky” feel web applications can have. But there are still issues. Here are a couple of things I don’t like to be honest:

1. It still looks and feels like a web page (which can be a positive – but for more complex applications this is a big negative)
2. You are still navigating around and waiting for a web page to come back (when requesting new pages)
3. Users can request “back” in the browser (unless the application has turned this off) or worse they think they should be able to go back…
4. Limitations on the application behaviour
5. Occasionally the server is still being used to deliver client side features (conversation that attracts data then updates a data grid on the web page)
6. Flexibility as a developer / ease in which to control the application

So let’s be honest, a web application still cannot compete with a good old fashioned “thick client” application installed on the PC for usability / user experience and performance….

The solution?

Well RIAs (Rich Internet Applications) hold the key. They bridge the best of both worlds in regards to thin client administration and thick client usability. This is more apparent for an intranet solution; there really is no excuse for keeping to old html based solutions.

In an intranet environment you can really go to town. You can deliver massive sized RIAs down to the client machine as you are on the network. More importantly with a little “caching” by your browser, the application need only be downloaded when an update has been made to the software.

Silverlight provides a great RIA platform, and allows intranet solutions to deliver the best of both worlds to businesses. Silverlight has many features built in that allows developers to manage how the application is delivered down onto the client machine, parts of the application can be split up and downloaded in the background ensuring the user doesn’t have to wait for areas of the application. Basically as a developer, you have almost a “thick” client environment to play with, allowing applications to behave just like thick client applications and provide the user with a far greater experience. This ensures processing that is done at the client end (such as displaying data) still all occurs on the client machine – with the client processor doing the work). There is a real separation between client processing, data, and server interaction (especially as the application utilises a Service Orientated Architecture)

However, you can also utilise the benefits of typical web pages, allowing state to be stored by the browser, navigating around in pages (if desired) and more importantly, not having to worry about client installations.

An issue – there can’t be?

There is just one problem with intranets being written in Silverlight or demanding Silverlight based RIAs. Most in-house IT departments will find they have any number of people who can “play around with HTML” or claim to be a “web developer” when really their skills are limited to modifying standard HTML. Even with typical ASP.NET and AJAX solutions, you will find that people with a basic understanding of HTML will be able to modify certain aspects of a web page / web application. With Silverlight, you need skilled individuals. This means companies have three options

1. Employ people with the skills (not cost effective)
2. Provide training for current employees to get some basic skills (again is this the best option?)
3. Utilise software companies on an ad-hoc basis (best on a retainer of some sort).

 

The Silverlight RIA payoff

Silverlight provides the possibility for intranet solutions to work as well (if not better) than typical thick client applications. This ensures usability, flexibility and scalability of solutions and opens up a new way of interacting with business applications through your intranet. There is no reason for intranet solutions to deliver “clunky” applications that users will not like to use, instead, provide “real” applications that empower your staff to do their work while keeping your IT administration to a minimum…

Do we need a web browser?

There have been a lot of discussions I have seen floating around on Twitter etc with regards to HTML 5, and will it kill Flash and Silverlight. To be honest, there is no way this can happen, simply because both Flash and Silverlight do not rely on a third party to make them work. In addition neither has to conform to a generic standard which can hinder their functionality. Both have product roadmaps and both move forward at a rate that such a generic implementation could never hope to achieve. This means, the user experience will always be (potentially) better, and that’s the main aim.

However, both Flash and Silverlight based web experiences do rely on a browser. A browser has to be used by the end user to locate the web site, and then for the Silverlight / Flash plug-in to be executed. After that, the browser is pretty much redundant…

In the beginning

In the beginning of the Internet, a browser was simply used to locate, access and display basic documents, that were formatted in a particular way in which the browser would understand. (I know, I am making this very simple, but I want everyone to see where I am going with today’s post). This allowed people to access these documents that were stored somewhere and read them. If you think of a browser as Microsoft Word for example, and the HTML as the actual document, you start to see where I am coming from…

Browser wars…

Jumping forward, and into the web as it was a few years ago (before social media, videos etc),  the browser started to become an integral way of accessing content on the internet. Using HTML format for the documents, the browser allowed users to use an address to find that content, then interact with it (move around the website etc). Now this is all fine, if you have one browser, or a set of hard and fast rule of standards that everyone conforms too. But we don’t, in practice that is…

There are many browsers out there, which essentially have the primary of displaying HTML content to you, the user. However, as users we want more. We want to have options to store favourites, access feeds, personalise my browser etc etc. We also want websites to do “things”. We don’t want to just read content. So what we end up with is companies fighting for us to use their browser, which in turn turns into a bit of a nightmare for web developers as their supposed standardised HTML gets displayed differently in different browsers. Worse than this, some functions just simply don’t work in some browsers…

Does browser wars actually help end users?

Old way of thinking…

For me the web has moved on. We are already saying goodbye to web 2.0, and some smart person will term web 3.0 before long (which will actually mean nothing different to web 2.0 or even web 1.0…) my point is, the web hasn’t changed its implementation, only we as users have changed the way we use the web and what we expect from the web.

The concept of using a third party application to access content on the web is old. I don’t like it at all. I also think that using HTML or any standardised format to deliver applications is plainly wrong. As a developer you are always being “shoe horned” into a way of thinking and working which hinders the application look, feel, interaction, and therefore detracts from your users experience.

Internet websites are no longer formatted pages of information; many now act as applications and with Flash and Silverlight, deliver highly rich, interactive user experiences. With such websites, the browser is simply used to find the RIA (rich internet application) and start it. The application isn’t run by the browser at all. So do we need a browser for this?

HTML 5 is supposed to deliver the ability to show video for example. However, the same issues will still apply between browsers and websites; they will just now be even more complicated.

A new way of using the web

In my own mind, HTML should remain as it is today, however, with standards (especially regarding CSS) tightened. HTML is fine at delivering content, that’s after all what it was designed for. However, delivering complete websites, rich user experiences should be left to bespoke software, such as Flash and Silverlight. This form of distributed computing power helps the end user, and enriches their experience. I see no place for a browser on my machine, and would rather see the ability to browse the web as part of the underlying operating system.

Websites can then be developed in whatever technology they require, such as Silverlight or Flash. These technologies then display the website / application as they should. The web is used to provide access and download the application / content, no need for a browser…

I hear some of you crying at this point “how will a search engine pick up the content”, which is a good point. However, search engines must adapt. Why can they not interact with Flash and Silverlight? With the latter, the content essentially is stored as xml, so it’s not a massive leap. Also, what’s stopping search engines from picking up on tags that describe the content fully, still within the hosting HTML?

HTML shouldn’t be seen as just something a browser understands, rather a format the operating system itself understands. Once this happens, and we use the web to distribute applications and information in this fashion, many of the headaches of the web will be removed, and we can truly open up the potential of distributed and mobile applications / rich experiences…Silverlight 3.0 already delivers an out of browser experience, so are we far away from this ideal?

Why we choose Silverlight…

To put it simply, it’s a matter of understanding “layers” of development choices. So by choosing a particular technology as a “layer”, your next technology “layer” choice is enriched by the previous, and so on. This means that when you compare a particular technology with a rival, in this case Silverlight Vs Flash, you find that the choice is made a lot easier for you, simply because of the “layers” it is built upon. I hope that made sense…..

I’m not going to be too technical in this blog, as I still want non technical people to read and engage in this topic. It’s one that I feel many “non technical” people will find cropping up more and more, especially as Flash has been unchallenged in the world of rich web experiences. Well until now…

Let’s start with the web…

Well, I have to be honest, in the world of web development I got involved a little later than some. My first experience of programming in a web environment was developing custom step processors for FileNETs’ eProcessor workflow engine. (Now part of the P8 suite and owned by IBM). At the time there were two choices, HTML or Java Applets. After looking into the requirements, and how to actually build the web interface, I quickly opted for the Java Applet route. Why? Simple, it made more sense. It provided a logical programming environment that didn’t seem messy. Using HTML with server and client side scripts, just seemed too messy, time consuming and far too prone to frustrating errors and bugs. Not for me….

While developing Java Applets, and some standard websites, my main development activities revolved around thick client business applications, almost all of which utilised COM based APIs (which all the business based applications I saw did at that time). And to be honest, I hated switching between the two very different ways of developing. When ASP.NET arrived, I was asked to start to develop thick client applications in .NET. However, I could now use the same platform to deliver web based applications and web sites. You guessed it, I soon moved away from the Java Applet form of thinking for my step processors, and standard ASP for our websites. To be honest, I thought it was Christmas.

With this in mind, there really was only one choice for me, a developer who developed traditional client based businesses applications but also web based applications / experiences.

 

The fundamental platform for us at One Degree, .NET

Once I formed my own development company (with a friend), we quickly chose our development platform of choice as .NET. For us both, it offered the greatest flexibility, allowing us to consume .NET components, COM APIs and XML Web Services (which were very new at that time). .NET really chose itself.

In addition, the development environment is almost as important as the technology you choose to develop in. Visual Studio is second to none. It provides an easy to use developer experience while providing all the tools you need to deliver enterprise wide solutions. You see why we choose .NET???

 

XML Web Services

Now why doesn’t all APIs out there utilise these? They provide so much interoperability and benefits to programmers that for me, it’s a no brainer. When I look at the web today, many APIs still don’t utilise these types of services the way they should. I find this a great shame.

Myself, and the technical Director at One Degree and OD Media, always ensure anything we deliver contains a full API layer. Sometimes we may only need to deliver and utilise XML Web Services, this is a mark to how easy they are to work with. By providing a separate location for our API layer, web services can not only serve our own applications, but also be opened up to third party applications / sites.  We also use XML Web Services for traditional thick client development. Our workFile ECM platform can be delivered as a thick client or as a website; both use the same XML Web Services API.

 

So why WCF Web Services?

Well first off, we are still in .NET and still using Visual Studio. This means all the benefits of developing with .NET 3.5 apply here, with our web services. WCF Services (.svc) are more flexible than the standard ASP.NET web service (.asmx), and as such more desirable. In addition, WCF now supports RESTful implementations, which again provide other benefits of choosing WCF.  

There is also the benefit to us, the fact that Visual Studio provides powerful templates to help get our WCF development started. Templates include RESTful WCF development, and development of services used by Silverlight applications. These templates drastically reduce the amount of time, and coding that a developer may have to do outside of Visual Studio.

 

Why Silverlight and not Flash?

Ok well I hope you have followed me to this point. So why Silverlight? Well Silverlight provides us developers with that next layer. It means we can still work in .NET managed code, we still have access to XML Web Services, we can still quickly and easily access other APIs, data centres etc and we can still work in Visual Studio. We have all the benefits of why we choose our .NET platform, but with Silverlight, we have the added dimension of delivering richer user experiences.

There are many comparisons out there now between Silverlight and Flash, however most of these it seems, concentrate on the simple “look” differences. This really isn’t a comparison; you have to look at the whole picture. If you are thinking of delivering rich web experiences, and you have no particular language preference, or no particular requirements to integrate with different applications etc, then the Silverlight Vs Flash decision is harder. However, Silverlight isn’t just Microsoft’s answer to Flash, it’s an extension of the .NET platform, and as such, Silverlight brings to the table a wealth of benefits that other web technologies, including Flash, cannot match.

Silverlight has a number of benefits when working on the web over its competitors (video streaming without streaming servers for one), and its competitors have some benefits over Silverlight (remember that Silverlight 2.0 isn’t even a year old yet). However, once you start to look under the covers, looking at the layers on which Silverlight sits upon, you see exactly why we, as a software and web development company, choose and recommend .NET, WCF services and Silverlight.