At the end of February, the official SilverlightShow Windows Phone app has been accepted into the Marketplace. The app gives you access to some of the content of this website, including news, articles and events, and is completely free for use (also ad-free!). Some of the convenience features include the possibility to create reminders for upcoming events and webinars directly on your phone, to get notifications about new content in the form of live tiles, and to maintain a local list of favorites that allows you to permanently store items for later reading. If you haven’t checked out the app yet, you can find more details and a quick intro video here, or visit its Marketplace page here.
The creation of the app was an interesting experience, because unlike other phone projects I had worked on in the past, this one wasn’t a greenfield development. Obviously the SilverlightShow portal already existed, had a long-established production infrastructure and already a lot of existing content available.
During the course of developing the application, we thought it would be a nice idea to share some of the experiences with the SilverlightShow readers, because it is a nice example of discussing a real-world application, with real-world problems (and solutions :)). The idea of this mini-series of articles was born, where you will discover both details about the development process as well as some technical challenges we came across. This first part will deal with the process itself, so prepare for some more text and less code (read: no code) than usual.
Prerequisites
With almost every piece of software you are developing, you usually (hopefully?) don’t start coding right away, but begin with some sort of requirements engineering, and then create the concept of your software. You may not be aware of the order and existence of these actions if you’re only a hobby programmer, or you may not be familiar with the formal terms and definitions, but even if you’re only creating a really small app, these steps are part of the development process in one form or the other. We can sum up these two elements by two simple questions:
- What is it our software is intended to do?
- How shall our software achieve this goal?
As I wrote, the details on how sophisticated you analyze these questions and the ways you maintain the results of this analysis is a direct result of several factors, like the development process you intend to use, your personal experience, external requirements, and the complexity of the project you’re taking on. Sometimes all this information may only exist in your head, in other situations it will result in huge documents being produced upfront.
When you’re developing an app based on an already existing eco system, there are additional steps you need to perform. In particular, you have to do an analysis of the existing infrastructure to see what parts you can make use of and integrate with your own development, how you can achieve this, whether other parts require work or need to change, and what features you rely on are missing completely. Sometimes, the intended requirements of the result even depend on what’s possible to achieve with a reasonable amount of effort, taking the given system into consideration. This is how extending an existing system can be both good and evil: it may speed up your development when you’re able to reuse components that are already available, but it may also limit your possibilities, and even bring up whole new problems that you wouldn’t have to face if you started from scratch.
The Existing Infrastructure
Building an app for the SilverlightShow portal wasn’t any different in this. The web site obviously existed already, and a great variety of people, consisting of both the SilverlightShow staff as well as external authors, actively contributes to the content. To allow comfortable and easy editing, the SilverlightShow team has put a great amount of work into integrating the site nicely with WYSIWYG tools, especially Windows Live Writer. As a result, the content available on the site is maintained in a blog-like manner, and stored as rich content in a corresponding data store.
On the consuming side of things, we have the web user interface you’re directly interacting with at the moment, but there are other options to access the content of the site which are optimized for machine/automated access. This includes several RSS feeds that can be consumed by special reader software, so you can access the site through your favorite client and presentation software. Some other areas of the site also offer specialized web services tailored for being accessed by Silverlight clients.
Since both working with the site itself as well as the authoring of content is a well-known, proven process that has evolved and been established over a longer period of time, it was a logical consequence to put the Windows Phone app on top of this existing infrastructure, and introduce as little changes as possible to the existing system. This was one of the first and most central requirements established in the development process of the app.
Requirements
Starting with the above information, we established a set of features we wanted to see in the app. In particular, we wanted to expose the most popular content of the site (news, articles, events/webinars), and at the same time make sure that we blend in nicely with the phone platform, by implementing typical features the user would expect: notifications, reminders, and a Metro-style native experience.
Concept
If you carefully read through the requirements and the result of the infrastructure analysis listed above, then maybe you can see how a lot of this more or less determined fundamental parts of the concept and later implementation already. Let’s pick some of the more interesting details, all of which will be covered over the course of this mini-series:
- Like said, we wanted to make use of the existing system and introduce as little changes as possible. A logical consequence of this was that we would make use of the already existing rich content directly if possible, so both the web interface and phone app could work directly on the same data.
- Another logical step of this was to use the already existing RSS feeds to get access to that data, instead of creating a whole new solution that would exist in parallel (and require additional implementation and maintenance costs).
- Consequently, that same premise also affected features of the app you would not expect or think about at first. Take the notifications requirement, for example. Implementing a full-blown push notification solution would’ve required setting up quite some additional server infrastructure and server-side logic, something that we didn’t want to do. Eventually, this resulted in the decision to use a local background agent to add the notification features to the app.
- Since we wanted to create a nice and smooth Metro-style experience with the app, we ruled out alternate ways of creating such an accompanying app pretty quickly. For example, I have seen quite some “wrapper” apps in the Marketplace that are using a web browser control to display a mobile version of a web site – simple, quick to set up, but in no way living up to the expectations of the SilverlightShow users and definitely not what we were looking for. We wanted to present a rich, familiar look and feel based on a native Silverlight implementation. And, after all, this is SilverlightShow.net, not WebBrowserControlWrapper.net :-).
Prototype
In some areas, we weren’t sure whether it really would be possible to achieve good results in terms of performance and user experience by using the concept we created. This is a common problem when you’re developing software: sometimes the complexity is just too high, or the involved technology is not understood well enough or has too many dependencies to allow for a definite answer and final design just by thinking about it in theory. In these cases, the way you should probably take into consideration is to create a prototype. This is a small piece of software that takes on the most pressing aspects of your concept and delivers a proof that what you intend to do will work as expected, or can work by modifying some details of the concept or add tuning – hence the naming “proof of concept”.
This is exactly what we did with some of the fundamental topics I have listed above. The small prototype allowed us to eliminate some mistakes in the concept that had slipped through, and to identify other issues we would be running into later on, which we now could plan for accordingly, early in the process. This very short phase of the development process helped enormously with clarifying some details and laying out the foundation and basic structure of the app.
By the way, the result of creating a prototype can also be that what you intended to do is not feasible – you should not think of a situation like that as a defeat, but a huge success. Imagine the wasted effort if you discovered the dead end only months after starting development. It’s much better to return to the drawing board early.
Implementation
For a passionate developer, starting with the actual implementation is the most exciting moment during a development process like this, after having built up all the excitement during the previous phases. And if you have worked on some projects like that before, you know that during implementation you get to crack the real problems, low-level, that nobody anticipated when they wrote the specs. Even when you have used advanced techniques like prototyping you will run into those pesky little details in your daily work that you hate, curse, and love to beat. So did we during the implementation phase of the app – some of these details and experiences will be covered in the next part of the series, and it will become a lot more technical then.
Conclusion
I didn’t go into the details of specific techniques of requirements engineering, creating specifications or even the implementation process itself. This of course exceeds the scope of this article. But whether you’re using agile processes or classic approaches doesn’t matter. What I wanted to show you is that things you may know from your day job can also be applied to this much smaller scale of creating relatively simple phone apps, and that it in fact helps with being more effective. I hope you enjoyed this first part, and are looking forward to dive into some of the technical problems we were facing next time.