Gary Fenn's Blog

Reflecting on Sitefinity & Beyond 2012

Gary Fenn — Thu, 19 Apr 2012 08:30:00 GMT

On Tuesday 17th April Telerik hosted Sitefinity & Beyond, their first conference for Sitefinity users, partners and developers. As Gold partners we eagerly signed up, and three of the team including myself went along for the ride.

Hosted in London’s stunning British Museum, we were surprised to see delegates from all over Europe: Germany, France, Italy, Finland and many more countries. It was very well attended and our hosts put on a varied show. I’m going to go through the sessions and summarize my feelings on each one.

Sitefinity 5.1 Preview

Ivan Osmak took us through a comprehensive tour of what we can expect in the upcoming Sitefinity 5.1. Don’t expect mind-blowing bells and whistles, it’s all about performance and stability in the latest upgrade. There’s also a Syncfusion-style service that converts files to PDF on the fly and by extension allows full text searching of the content. There’s also some simplification in the cross-publishing services, but more on that later. Ivan also promised “zero known bugs” for release in the eCommerce module. There was also a suggestion that the entire Sitefinity back-end will be recreated in KendoUI instead of the current jQuery-flavoured interface, which should see a number of percetible performance gains. A very interesting presentation. As I tweeted at the time: “[Ivan] is no Steve Jobs but he is an honest developer who clearly loves the product.”

Reaching New Heights with Sitefinity Thunder

Thunder is an upcoming plug-in for Visual Studio that tightly integrates the IDE with Sitefinity. As a Microsoft house this is music to our ears. We’ve been around for a while and can remember the whole heap of files that need moving around to customise, deploy and maintain a Sitefinity website. In the leaner database-orientated approach this is much more versatile. Thunder extends this versatility by communicating directly with the live (or more likely in our case UAT) site via a web service call. The demo that Ivan showed was very impressive, and we’re keeping a close eye on this one. There’s a webinar for Thunder this week we will be paying attention to.

Migrating Your Website to the Latest Sitefinity Version

This was getting a little rushed so Ivan didn’t spend a great deal of time focusing on this, instead he spoke about how the safest migration path is from Sitefinity 3.7 SP4 upwards. Telerik are also knee-deep in a migration of their own site; in conversation with Sitefinity Partner Manager Oggy later he admitted the site is unrecognisably 3.7 anyway as almost all of it had been customised through the years. It’s a very complex undertaking.

Creating Feature-Rich Custom Modules

Businss Analyst Hristo Borisov took the stage here describing his own pain points in trying to encapsulate customer needs accurately and how Sitefinity module builder can get prototypes off the ground to iterate towards the ideal solution. He showed off a flashy module that allowed for banner ad placement with no HTML knowledge by the content manager that was impressive, but a little fast for me! It got my colleagues’ juices flowing however, and they almost wanted to turn back to the office and make a start!

Going Mobile With Responsive Design

Product Evangelist Gabe Sumner took to the stage for this one, with a confident and informative demo of the responsive templates within Sitefinity. Whilst we haven’t used this on a client project yet we have explored the features on a test site. It’s certainly an impressive and very easy to use feature that has a lot of possibilities. Gabe also went beyond the technical and asked us to consider that articles will be given different prominence and this will affect how they are perceived. However the room got a little tense when the pricing of this feature came up. Both sides raised good points but it’s clear the community is having a hard time trying to sell this proposition to clients.

Multi-Channel Campaigns: Where Marketing and Technical Meet

This one will get the digital marketers salivating: improvements have been made in Sitefinity 5.1 to help connect all the publication channels so 1 piece of content can be syndicated across RSS, Twitter, Facebook etc. A good feature and can't come soon enough for those of us looking to get more eyes on content. More details on the Telerik YouTube channel.

Sitefinity as an Enterprise Level CMS

This one intrigued me as we have had a few requests from customers to implement such a scenario, and whilst we have implemented it once I wasn’t completely happy with the elegance of the solution. Sitefinity partner Avaus put forward a case study that was certainly detailed, but perhaps a little dry for the majority of the room. That said if we get another similar proposal I’ll go back to Avaus for any tips they can offer for making TFS work better with the multiple config files required.

Beyond Development – Be A Hero

Boris of United Experts put forward essentially a “hints and tips” section with a few gems in there. By this point I think the delegates were burned out from excellent demos from Gabe, Ivan and Hristo, and Boris was up against the clock to get through his presentation. The GZIP sample code and taking a little time to customise the Content Editor were good ideas that we’ll look into.

Conclusion

In all the event was a well-attended and varied conference that served a number of different audiences. In the end that was also the negative – the room was a mixture of technical and non-technical people and it was difficult to satisfy everyone. Next time it would be good to have the conference diverge into these different audiences. The presentations by the Sitefinity staffers were by far the more engaging and encouraged the most feedback. I'd really like some time with builds of the product while we were there as you want to play with the features discussed. It was also very useful to meet the Sitefinity team face-to-face and put real faces to the forum posts.

Roll on Sitefinity & Beyond 2013!

To Sitefinity... and Beyond!

Gary Fenn — Wed, 18 Apr 2012 12:00:00 GMT

Yesterday three of the Light Speed team including me went to the Sitefinity & Beyond conference in London. It was an inspiring and thought-provoking show and the first of its kind that Sitefinity have offered. I'll be covering off the main topics and my review of the day in a later post, but here's a couple of snapshots that illustrate the day.

Hristo Borisov led a seminar in building feature-rich custom modules. He also put this true fact on the screen!

Our front-end developer Alex takes a break. Isn't it amazing how much caffeine helps knowledge intake!

Using User Stories

Gary Fenn — Sat, 31 Mar 2012 10:35:00 GMT

One of the artefacts of many agile methodologies, particularly Scrum, is the User Story. Depending on your background you may have a different opinion on what this phrase means. If you have any experience in development you'll probably translate the phrase in your head into "use case".

A User Story has a certain slant on it: it helps revolve the development around the user. Rather than getting excited and trying to build the most high-tech and capable system with all bells and whistles, grounding development in User Stories means a feature should only be considered if it has a direct benefit to a user.

A User Story has an ideal format that helps structure them:

As a <user> I want to <action>, so that <benefit>

Essentially, you're trying to crystalize a feature or idea into one simple sentence. The user is often a number of groups: from internal users of a system, to system admins, to members of the public to the CEO. Everybody will have a set of Stories that correspond to their needs. The last bit is optional if the benefit is self-evident. That doesn't mean it is assumed, but should've come up in discussion. Each User Story should be debated so they stand up to the customer's requirements and that everyone on the team knows what a system is trying to achieve.

There are lots of arguments to be had about what features of agile methodology are the best and what should be used but this one makes perfect sense.

There are more resources online (pages and pages of them!) but I think Agile co-founder Mike Cohn has the best articles:

Choosing the Right Tool for the Job

Gary Fenn — Sat, 31 Mar 2012 09:49:00 GMT

Once you start going down the road of agile software development, one of the first things you think about is how you’re going to keep records of everything. You can’t beat whiteboards or pen and paper, this stuff is good for the big picture, but at some point you’re going to want to draw all this data into one place, report on all of it to your stakeholders, and make it available on the web to relevant parties at the same time.

Internally we use Team Foundation Server to track our metrics and that works well for us, however there are advantages to being located in one office. What if you have multiple teams in different areas? You need a web app for the job!

There’s no end to web-based applications out there related to project management: Basecamp, TeamPulse, ProjectorPM... a quick search will throw up tons of resources with free trials and pages of benefits to absorb. While they are all performing a similar function, there’s usually a feature in one that you would like that isn’t ready yet or they have no plans to implement. And it’s not usually until a month or so in you remembered that you needed that feature! So how do you choose?

A great site I like to visit is Web.AppStorm. AppStorm is a site devoted to reviewing and comparing the best gadgets from around the tech world, and the web version. On the Web portal there are quick looks, in-depth reviews and comparison articles, packed with loads of great information to help you decide which app is going to work for you, without having to take dozens of 30-day free trials to reach the same conclusion!

There’s all kinds of categories in there, from note-taking to document storage, from agile software development to calendars. Web.AppStorm is a great resource for researching and evaluating online tools.

14 Million QR Codes Scanned in 1 Month

Gary Fenn — Tue, 22 Nov 2011 09:47:00 GMT

Following our blog last week regarding QR codes, Top SEO Liverpool have created a very cool infographic pulling together various statistics on the use of QR codes.

There's a number of interesting bullet points to take away:

53% of users are between the age of 18 - 34
14 million Americans scanned a code in July 2011
46% who scan QR codes do it for discounts

Head on over to their site now to see this interesting graphic.

Cracking the QR Code

Gary Fenn — Tue, 15 Nov 2011 12:00:00 GMT

Recognise the image on the right?

If this weird mess of blobs and dots means nothing to you, this is a QR Code (Quick Response). Some text is buried within this pattern and could contain almost anything though what they are most commonly used for is a quick way to give people a link to a website. Most smartphones come bundled with an app that lets you read the code using your camera or apps can be downloaded for free. If you have a smartphone handy, try scanning the code!

QR codes are all the rage in marketing at the moment as it's a handy and useful way to get a customer to use a link when all they have is their phone nearby, so it can be used on posters, billboards, signs... you name it. Some TV programmes have been using them as shortcuts to other information, such as cooking programmes providing links to recipes via the onscreen QR code.

As a software development company we've recently finished a project for a customer revolving around these distinctive designs. Using a freely available QR code library, our customer could import a batch of URLs, have QR codes generated for them, then were able to charge their clients through the same app for them to be distributed via print. It's a clever end-to-end solution hosted in an online app with full security for handling payment details.

If this sounds like the kind of thing you need, get in touch.

A Method to Our Madness

Gary Fenn — Fri, 21 Oct 2011 22:23:00 GMT

Hofstadter's Law: Any computing project will take twice as long as you think it will -- even when you take into account Hofstadter's Law.

There are frequent newspaper articles and new reports of government or large corporate projects running late or massively over budget showing that there is some truth to Hofstadter’s Law.

Why is this case? Software development is highly complex undertaking requiring skilled people to design, implement the application and to manage the process. It is also a relatively new field of engineering. In the early days of programming, programs were small and could be written in a few days by a single person. As computers become more powerful, the size and complexity of software grew proportionally. More and more people were required to develop and manage the applications and thus the first generation of development methodologies were born. A software development methodology is a process that is used to organize, control and plan a software construction project. Ideas were taken from other fields of engineering and melded together. These proved to be flawed and there was little interest in improving them.

In recent years more and more emphasis has been placed on improving the process of development. Here at Light Speed we have invested heavily in our staff, the technology we use to build software and in enhancing our development processes.

Before describing our processes and their strengths it is useful to know the weaknesses of the most commonly used methodology.

The waterfall model on first appraisal seems quite logical and sensible but it is deeply flawed. Waterfall traditionally has five phases:

Requirements – gathering the needs of the users
Design – deciding on the structure if the application and its subsystems
Implementation – writing the code
Verification – testing the code for bugs and ensuring requirements are met
Maintenance - fixing errors after release and modifying the application to changing needs.

By looking at the stages it is clear that there is a lengthy period of time from gathering requirements to the end user testing the application ensuring that what is built is suitable. A leading cause of failed projects is that user requirements were not clearly understood and an application which did not meet their needs was delivered.

Gathering requirements is a difficult task. A software developer is an expert in his own field and the users of software are experts in their own. Each domain has its own jargon and implied knowledge. It is challenging for software developers and designers to gain a good understanding the users domain especially at the very start of the project. Requirements are likely to change. If the project has a lengthy duration, the requirements at the start can be quite different to those at the end of the project since the business world is in a state of accelerating change. With the waterfall model it is difficult and expensive to update the code as these needs change. A change in requirements in the testing phase is far more costly to implement than a requirements change in the design phase.

As each project is unique there is no methodology that is ideal for all types of projects therefore we adapt our processes to the needs of each individual project. I will briefly describe are most frequently used approach.

We do initial requirements gathering but we understand that these are likely to change and plan accordingly. The fine details of requirements are deferred until they are about to be implemented. We also do an initial design to guide the development process but at a much less detailed level than is seen in the Waterfall model. Requirements are prioritised by the client with assistance from us so the most important needs are completed first. Requirements most likely to change are completed as late as possible to minimise rework.

We typically use an evolutionary and iterative approach to design and development meaning that the application will be built incrementally. A project can consist of many iterations. Often each lasts a few weeks only. At the start of each iteration, the requirements to be implemented are selected and fleshed out with the client. Then the detailed design work is carried out. After this, the requirements are implemented and tested in detail. An iteration is not considered complete until it has met all of the client’s acceptance criteria.

Testing occurs throughout implementation and not just at the end. This permits the client to evaluate that the requirements are being met during development and not at the end when it is too late. The impact of changes to requirements is greatly reduced since detailed requirements gathering and design is done just before the requirement is to be implemented.

Many of the problems that face software development projects can be mitigated by using the correct process while choosing the incorrect process can easily doom any project. At Light Speed we take great pride in the effectiveness of our own methodologies. We review the performance of our processes during and at the end of each project to learn lessons and to improve for future projects.