In this white paper the article author Kevin Dockx revealed the challenges behind building a Silverlight-powered 360-degree employee review solution with his company RealDolmen. You may address any questions on this white paper inside the Comments section below.
Company Profile
Company name: RealDolmen
Website: http://www.realdolmen.com/
Industry: ICT
Brief company overview:
RealDolmen is one of Belgium’s largest ICT companies. We are a single-source supplier with wide expertise in various sectors (professional services, infrastructure, support, …) and technologies (the full Microsoft stack, Java, CAD/GIS, …). We have over 10.000 man-years of experience of service, a wide portfolio of ICT skills and a strong network of partners.
Project Overview
1. Describe what the project is about - goals, target users, key functionalities
The project, named 360 review, is all about automating 360 degrees review of persons, resulting in a report. A 360 review should be seen as “one person gets reviewed through a certain survey by a number of colleagues (and by himself)”, and this person is reviewed on a variety of subjects. The project has been designed to be offered in a Software as a Service model, with ease of use and reuse of inputted data in a multitude of languages in mind. The general business model is that a company that wants to engage in a 360 review of its employees comes to us, and we set up a client environment for this company. In that client environment, the company can input its employees, create questionnaires, start surveys and create reports from filled-out surveys. Once a survey starts, mails are sent out to the people that have to fill out the survey, and through the login details in that mail, they can open the application module which allows them to fill out the survey.
So, the project consists of 3 parts: the Management part, which allows the administrator (that’s us) to create new client environments. The Client part, in which a client can manage questions, persons, questionnaires, surveys, … And the Employee part, in which an employee can fill out a survey created in the Client part.
High on the list of priorities were an intuitive, easy-to-learn & fault-tolerant user interface, and low bandwidth use.
2. Did you have any limitations set - technologies to be used, time, resources, etc?
The technology choice was actually quite easy to make: as we needed a performant, intuitive user interface, combined with low bandwidth use, using Silverlight was a no-brainer. As with all projects we undertake, a budget is set in advance, so of course time & resources are limited.
3. How was the project team composed?
With all projects, we have functional analyst, technical analyst, general project manager, test team and developer roles. The key difference with this project was that we added a designer/devigner to the project team. To get a good user interface, that role is absolutely essential. Creating a good design takes up quite a lot of time: we had one devigner for 2 developers, and he was on the project during the complete duration of the project – but it was definitely worth it.
4. What Silverlight features were used in this project?
Almost every feature you’d expect in a line of business application: of course we used the data binding features heavily, but we also used parts of the Silverlight Toolkit (eg: TreeView, Charting), parts of the navigation framework, a bunch of custom controls, custom styling/theming and animations, validation, localization, … Data access is done with WCF RIA Services, backed by the Entity Framework on a SQL 2008 R2 DB, using both generated entities and custom DTO’s where necessary.
We also used a custom, internal reference architecture which filled in the missing parts (eg: we have a custom navigation framework built on top of the one that’s already available, allowing us to specify exactly which role has access to what part of the application, we have rules and components for caching, logging and exception handling, we have all the necessary classes for MVVM, services for dialog windows, services to trigger animations, …)
5. Project snapshots
(Click on the pictures for a larger view)
Problem and Solution Insight
1. What were the pros and cons for using Silverlight to achieve those goals?
A big pro is definitely the almost unlimited UI customization options Silverlight offers. The fact that Silverlight runs on the client was also a big pro – for example, we generate reports client-side: all we need is the data to generate it with. In our case (where the needed data for the report, which includes quite a few graphs, is much smaller than the resulting report itself), this means the bandwidth usage is lower (as the reports don’t have to be sent to the client, only the data needed for the report). Performance-wise, an average report 25-page report including graphs is generated in about 2 seconds on an average client machine – and we don’t depend as much on the amount of concurrent users generating reports on the server. In general, keeping performance in mind for this specific application, Silverlight is the right choice: once the data is available, all operations are done on the client.
A con was the availability of the plugin for possible customers: at the moment we started the project, it wasn’t as widespread as it is now. But currently, around 70% of internet-connected computers have the Silverlight plugin (source: riastats.com), so that isn’t an issue anymore.
2. What were the major Silverlight-related problems faced during development?
When we started development, we were working with Silverlight 3 and the then available version of WCF RIA Services, in Visual Studio 2008. By the time the project was completed, we were using Silverlight 4, Visual Studio 2010, and the latest version of WCF RIA Services. That means we went through 2 Silverlight versions, a new Visual Studio and 3 versions of WCF RIA Services during development – and some upgrades included changes that broke previously working code, especially in relation to WCF RIA Services. The main Silverlight related problem was definitely fast release of new versions: we lost quite some time because of that, and we had to throw away quite a bit of code we created for Silverlight 3 to support certain features that became available out of the box with Silverlight 4.
3. What was the reason to choose WCF RIA Services for data access? Did you consider other technologies as well?
Low bandwidth usage (when used correctly), client-side change tracking, built-in validation on client/server and the ability to precisely choose what’s going over the wire through metadata and change-tracked DTO’s are all reasons to choose for WCF RIA Services. Next to that, the built-in security options (Authentication Domain Services) obviously saved us a lot of time & effort.
For example, we didn’t want to submit every change in data to the server immediately: we wanted to keep this on the client and let the client decide when to sae the changes (resulting in a less chatty application). Having out-of-the-box change tracking really helps in scenarios like this. In essence, you can look at WCF RIA Services as having an Entity Framework-like ObjectContext to load data in, keep track of changes, … on your client.
WCF RIA Services is often marketed as a framework for rapid application development, which it definitely is, but it’s a lot more than that: when you starting looking at it more closely, you’ll find a very powerful, very extensible framework. You get so much out of the box, and if you need something else, it’s pretty easy to add. But you have to look past the marketing talk ;-)
4. Did you face any challenges with using navigation in your application?
Yes. We wanted to support deep linking, which drove us to the built-in navigation framework, but we quickly noticed that it isn’t sufficient (at all) for complex applications. For example: we needed to be able to navigate to a certain Uri, which had to create the UI by loading different views in different frames, and we had to be able to navigate to a certain “state” of a view, automatically. This kind of behavior isn’t available out of the box, so we heavily extended the existing navigation framework to get what we need. Through these extensions, we are now able to define a Uri and link it to different views in different states in different frames, and even define whether or not authentication/a certain role is required to access the Uri.
5. Did you use any third-party controls? (which one and why, if appropriate)
We used some controls from the Silverlight toolkit, but next to that we created all our controls ourselves. They were too specific to be available through third-party vendors, and it’s actually quite easy to create custom Silverlight controls.
6. What did you use for reporting?
For reporting we were looking for a solution which allowed us to create reports (in this case: Word documents) on the client. We evaluated a few possibilities, but SyncFusion DocIo really stood out for us: you can start from a template, easily fill in the data that’s needed and send the report to the client through a typical “Save as” dialog window. It’s also quite intuitive to use, and we had used the non-Silverlight versions of their reporting tools in the past, so we already had some experience with this.
Conclusion
Were the initially set goals achieved, within the expected resources? What else has left to be improved?
The initially set goals were definitely achieved, but we did experience a bit of overrun because of the various migrations we had to do due to the fast pace of new WCF RIA Services / Silverlight versions. However, we’re very happy with the application at the moment, and we get similar feedback from companies that use it.
As for possible improvements in the future: there are always things we can add, more functionality, extra graphs and reports, … This project will keep on evolving day by day, depending on customer feedback.