Our Blog

where we write about the things we love



Project Siena – The good, the bad and the ugly

I recently created a Project Siena app to showcase how easy it is to create a Windows 8 app without writing any code. As a developer losing so much control over a solution can be frustrating. Here are my thoughts.

Project Siena is a Windows 8 app that can be installed on any machine, and provides a drag and drop experience for creating an app.

This is the good part of Project Siena. If you have a design that you want to bring to life as a proof of concept to show a client, Siena could fit this purpose easily. Siena has enough prebuild components to show how we can display data. But thinking of it as any more than this could be dangerous as there are a host of limitations and gotchas that can leave you screaming at your computer screen.

Project Siena canvas

Even the designer falls down in a couple of places. There is no responsive design, which is simply a must for any Windows 8 app. Also opening an app in split view will hide half of the screen with no way to access it without closing the other app.

Out of the box Project Siena supports a few popular services so you can see some real results without much trying. Just by dragging and dropping you can have Youtube videos or a social Yammer feed in your app. The pain with these services is that for every service you decide to include the user needs to log in to each one every time they access the app.

One of the things that is meant to sell Project Siena is, in my opinion,  its biggest downfall: connecting to external data sources. You can connect you own services up to the app in two different ways, Mobile Service and REST Service. The Mobile Service requires you to create another custom service and implement in such a way that Siena can read it. Once that is set up you are then restricted to only 300 rows of data per table. This is also loaded and cached on program start. This makes showing more complex data difficult, as you have to make sure that all linked data is loaded on start.

This data load contributes to another pain point in Project Siena: it’s slow. Painfully slow. This data is not loaded until the app is completely loaded up, so if you are loading this data into the main page then the user is going to experience a very empty page for the few seconds it takes to load all of your mobile services.

To interact with the REST Service Siena requires a WADL file to define how the services work. This is an uncommon specification that is difficult to hand roll and only has a single beta tool for generating. Authentication against your service is possible but only by providing a common key with the WADL file. Although with a lot of work it is possible to authenticate on a per user level, I was unable to find any secure way of implementing this that didn’t require sending plain text passwords over the network.

Once you are done with the initial build of your Siena app, you can publish the code and open it up in a Visual Studio Project to develop new features and publish to the store. This is where the ugly comes in. Generated code is both a development and maintenance nightmare. And this is especially true in the case of Project Siena. You would save a lot of time, money and frustration by rebuilding your app from scratch.

Looking on the horizon for Project Siena has some promising features on the way that may negate some of the issues that I found with it. 

So, in conclusion, Siena is a great tool to mock up your project in an afternoon to show what your app could look like in a completed state, but be careful when you venture further in. There be dragons!

Posted by: Lee Farley, Developer, Seattle | 01 December 2014

Tags: Mobile applications, Developers, Modern User Interface, mobility, design

Blog archive

Stay up to date with all insights from the Intergen blog