(X) Hide this
    • Login
    • Join
      • Generate New Image
        By clicking 'Register' you accept the terms of use .

Building a Silverlight Line-Of-Business Application – Styling Part 7.1

(5 votes)
Chris Anderson
>
Chris Anderson
Joined Sep 29, 2008
Articles:   8
Comments:   62
More Articles
7 comments   /   posted on Mar 26, 2009
Categories:   Line-of-Business , Design

This article is compatible with the latest version of Silverlight.

Introduction

In Part 6 of this series I looked at implementing a means for displaying reports that appear to be within the application and permitting them to be printed. In each of the articles so far I have discussed major components of line of business application development, but have spent little or no time in styling the application in anticipation of writing an article dedicated to doing so. However that article has turned into seven articles which will become a mini-series within this existing series. Over these articles I will discuss some user interface design theory, Silverlight styling concepts, and design tools; then I’ll move onto restyling the framework of our application, converting our user controls to custom controls, restyling the content pages, and covering using the ImplicitStyleManager (a part of the Silverlight Toolkit project). To start with though, in this article I will discuss my opinions on the importance of making your application attractive.

Before we start, I have a disclaimer. I’m a developer, not a graphics designer – so I’m writing these styling articles from a developer’s perspective (and with the same limited graphical design skills many other developers share). I have spent a lot of time as a developer producing user interfaces as a part of the systems I have designed though, so hopefully I can provide some useful information that I have gained over the years to other developers from my own trial and error experiences - though these are not necessarily the opinions of an expert in this area. I have built up my own philosophies on user interface design that I practise (of which this particular article is predominantly composed), so please feel free to question these and provide your own alternative (or additional) views in the comments.

Source Code and Live Demo*

Instructions on setting up the sample project can be found in Part 1.

To log into the sample application use the following Username: demo and Password: demo

Why Style Your Application?

The big question to start with is why should we concern ourselves with styling our applications and why is it important that our application looks attractive? No doubt when you first look at the application we have been building your first impression is something along the lines of “my god that’s one ugly application”. And I would agree – that was by design (mostly) – I spent very little time on the visual aspects of the application, preferring to focus on core functionality first. I think it’s fairly representative of what an application produced by a developer with no designer involved might look like (based upon what I have seen published by other developers around the web). Now we have reached a point in the development process where we have proven the capabilities of Silverlight as a runtime platform for our business application and proven its suitability, so now it’s time to focus on improving the user interface design to make it more visually attractive. Personally I’ve met very few developers who are talented in both coding and graphics design. I’m not saying they don’t exist (I have met a few talented in both areas), but from my experience they tend to be mutually exclusive mindsets. Often developers are more concerned with making something work instead of look good, therefore building attractive user interfaces is not always at the top of the priority list, and often outside their skill set. Ultimately the application will be judged on whether it works, containing the required features and functionality to achieve its goal. However the importance of the attractiveness of the application and its effect on the user experience cannot be underestimated in having users accept the application into their work environment.

I have a particular philosophy when designing applications to get acceptance of a new application with the users. Often there is a deal of resistance when introducing a new application into an organisation as it’s a part of human nature to not like change and work outside your comfort zone of what you’re used to. As developers we often thrive on change and learning new technologies, but we have to remember not everyone shares our enthusiasm for new challenges. Therefore we need to take this into account and find a hook to get users “on board” and impress them. I believe there are three aspects in designing applications required to gain the approval of users for a new application: you need to capture their eye (it must be visually appealing), their mind (it does what they need, in a straightforward and simple manner that makes their job easier, not harder), and their imagination (it excites them and sparks ideas for how much better they can do their job and streamline/monitor their business processes). If you can target each of these areas then you are much more likely to garner a might higher approval rating and faster acceptance of a new application.

Once case study worth discussing is that of the Facebook layout changes. Recently Facebook has redesigned the structures of their pages a couple of times, each time with a huge uproar from users upset with the changes, despite each (in my opinion at least) being major improvements on the previous versions. It wasn’t because the changes didn’t work, or that features had been removed - ultimately I think you can narrow the fuss down to it simply being different to what they were used to and needing to adjust accordingly. Given time they get used to the new layout, get over it and learn to love Facebook again (until the next change is made). Every new application introduced into an organisation faces this same challenge – users rejecting the application because it forces them to work differently to how they did before. To overcome this resistance to change you therefore need to give them something to like about the application and impress them in order to gain their approval. Often simply making it pretty can do the trick.

Unfortunately as humans we tend to be very visual creatures – whether on the hunt for potential mates or simply evaluating new software applications, initial interest is often gained visually - providing the path to further investigation and sizing up for suitability. Therefore we need to work with this trait and cater for it accordingly to bypass the initial barriers. In addition (or perhaps as a result) people often judge the quality of the application at first impression by how it looks – in other words the attractiveness of the user interface (external appearance) can impact the user’s impression of the quality of the underlying code and thus whether it is up to the job – whether it is likely to make their lives easier or cause them pain. As the saying goes, first impressions last. It’s not a rational decision making process (though can often be a good generalised indicator as it’s not unreasonable to expect if the user interface is well designed then so should the underlying code), but we need to take it into account. Another thing I’ve noticed (I must note this is not scientific data I’m quoting, but more anecdotal in nature), the more attractive an application is, the harder people will try to make it work, and the longer they will persist before giving up.

There is one more compelling reason to have an attractive application, and that is in the sales process for shrink-wrapped products. For much the same reasons that it is important to get the instant approval of users (when developing an in-house or custom application for an organisation), you need to also get the instant attention of those making the decision of what product to buy. In fact (again only anecdotal evidence) sometimes a choice between products may be made if a product is more attractive than its rivals, even though it may be more expensive or contain fewer (non-essential) features. In these scenarios, investment in good user interface design can pay dividends when it comes to sales. You need to aim to make the buyer say “wow” – at which point you have them hooked.

When Should You Style Your Application?

So when is a good time to focus heavily on the design of the user interface? If you spend too much time too early in the development process on the design then it will mean a lot of extra time that will have been spent on the design due to reworking when things are rearranged (as they inevitably are early in the project, often based upon client/user feedback). Your first presentation to the client will be their first opportunity to visualise what you will be delivering. Because software design generally isn’t the client’s world they often can’t visualise what they want or will be getting, and this presentation will (should) bring the concepts together for them. You can always expect a flood of ideas and changes (and additional requirements) to come out of this first presentation, and having spent a lot of time on the design and look of the application before then could result in a lot of wasted time. However, this is your opportunity to impress the client and reassure them they made the right decision going with you as a developer, and having an attractive application to present is much more likely to help in this mission. But they won’t be impressed if it’s all look and no functionality. Finding that balance is not an easy task. The best option probably would be to work from an existing (preferably attractive) template and insert the custom functionality into it while prototyping (or ramping up), and then redesign it at a later stage in the development. There are a lot of free HTML/CSS templates available for web developers, however there is little in the way of good premade templates of various designs to work with currently available for Silverlight applications, and this area is still a void waiting to be filled in the Silverlight community. Hopefully the outcome of these styling articles can be considered a good starting point for many new Silverlight applications going forward, though a lot more designs are required to suit different purposes.

Integrating Design With Development

Silverlight and WPF applications both provide the means for unique and flexible UIs, but gone is the ease of designing UIs to pre-existing guidelines such as you would have with Windows Forms applications. In fact, in both Silverlight and WPF “out of the box” you have little in the way of a visual application template (it’s more akin to a blank slate) which can be quite confronting for developers new to these technologies. Because of this, while we can expect more beautiful applications (due to not being locked into a specific design and the flexibility of the XAML framework), we can also expect a lot more ugly ones as non-graphically minded developers attempt to hack together user interfaces with little predefined visual structure and colour palettes to help guide them. Therefore these technologies almost demand the need for a designer on board. Incorporating designers into the development process has been a focus for Microsoft of late to enable unique and visually appealing applications to be developed. In order for developers and designers to work together, Microsoft has designed the Visual Studio and Expression Suite toolsets accordingly to enable developers and designers to work alongside each other on the same project in harmony. The downside is that without a designer available, developers will need to learn another tool (Expression Blend) and constantly switch between that and Visual Studio to perform their job. Unfortunately for developers, user interface design is no longer a simple drag and drop affair. But these articles aim to help developers get on the right track when there is no other option.

Our Target

Our aim in these styling articles will be to turn our application from something rather unattractive like this:

To a somewhat more attractive application like this:

(Note that only the framework has been styled, not the content pages as yet – this is to come)

This framework will be templatable and stylable, so its appearance can easily be changed without altering the controls that provide the structure themselves.

Conclusion

I believe a definite emphasis needs to be placed on producing applications that are both visually appealing and easy to use (in addition to working as specified). It’s often a topic that is overlooked as a whole with the general focus (as developers) being making something work rather than attractive. This article has mostly been an opinion piece, but I’d like to think it may start some much needed discussion and debate, and hopefully some action too.

In the next article I will be taking a look at fashions in user interface design of late, and what basic elements can be identified as working towards beautiful and functional applications.


Subscribe

Comments

  • -_-

    RE: Building a Silverlight Line-Of-Business Application – Styling Part 7.1


    posted by Jesus on Mar 26, 2009 12:16

    Hi Chris,

     

    First of all, congratulations for these “Line-of-business” series, and thank you because are really interesting and productive for all SL Developers.

     

    I’m really happy to see that you’re going to include some visual improvements to your framework, although it’s on the 7th chapter. It doesn’t surprise me because it’s a traditional approach for a developer as you commented, first create things that show data, second… third…… seventh try to put them as beauty as you can….

     

    But from my humble point of view, especially if we’re on Silverlight scenarios, that’s actually a big mistake and it turns Silverlight into “GreyLight”. Silverlight is an amazing technology that allows developers to create impressive user experiences, and that should be considered even in line-of-business applications.  You cannot put some text boxes, menus, buttons, to vomit a grid and say to designers… -Do your Job, and try to solve my lack of artistic talent-

    What a designer could do with that?? Where’s the integration between Design with Development???…. that’s more like “enhancing my development with small drops of design”. That’s like if a Car design depends of the size of the engine or decide that the wheel rim of a truck are the best before design a small car.

     

    That’s been the approach of developers for years, and it’s a fact that there’s no difference between your screenshots and the ones I’ve got archived in developments from 1998 based on html+css+javascript. What’s is going to be the business justification to change if you show exactly the same look&feel. I think that’s the main reason the BDMs are rejecting to impulse Silverlight on Enterprise environments, and also the reason why Designers are not adopting Silverlight easily.

     

    Please, let’s try to evolve and talk about real Des-Dev integration, or avoid it. By the way, when we talk in some way about integration, we should say better Integrate Development with Design, not Design with Development. Interaction Design should be the first thing before write any control, and even before any Visual Design, because an interaction designer is going to ask himself if a traditional button, a menu or a grid is needed before to put those things there.

     

    We (developers) need to change our minds and avoid the technology excuses we always used, and say to Designers…. “Hey guys, with Silverlight we can now create all those things you imagined before even for Line-of-Business applications and we always said it cannot be done, so tell us which is the best approach for representing those data”…. That’s a real Des-Dev workflow, and integrating Development with Design.

     

    Excuse me if I haven’t been so polite but it's really frustrating to see always the same approach through years and years, with every new technology, and of course sorry about my English because it’s not my native language.

     

    Thanks,

    Jesus

  • -_-

    RE: Building a Silverlight Line-Of-Business Application – Styling Part 7.1


    posted by Laith on Mar 26, 2009 21:08
    Well put, Jesus. I agree completely.

    I think most developers are getting really lazy, and they limit the application's capabilities and beauty by using the drag-drop-databind methodology. I think that's the cheap way out, and the designer's imagination is going to be limited by these built-in controls.

    All the tutorials, blog posts, MIX videos, and screencasts look exactly the same. No one has created an application with any real design. Remember, in a line-of-business application, it's not the developer you need to impress, it's the business. If clients look at these Silverlight demonstrations, they're going to ask "What's so special about this?"

    It's up to us developers to push Silverlight to its limits.

    Cheers.
    Laith
  • -_-

    RE: Building a Silverlight Line-Of-Business Application – Styling Part 7.1


    posted by Bob Baker on Mar 26, 2009 23:48
    Again, congrats to Chris on a great series!

    I am as guilty of any of building apps that look almost the same as my 1997 editions. I have attempted to learn to glisten up here and there, but it's not easy finding a designer who doesn't want bright red flames and black everything (I'm serious). Of all the new silverlight stuff out there, I think Infragistics and Telerik have cornered the market on designers who 'get' data presentation and manipulation. and the role it plays for the producer/consumer. Take a look at Telerik's version of the Northwind demo. It's almost intuitive, which is what I believe the designer side claims to be able to do. That said, I certainly did not see anything impolite in the posts above, and I think this is a serious discussion that is extremely worthy of continuing.

    best,
    Bob
  • -_-

    RE: Building a Silverlight Line-Of-Business Application – Styling Part 7.1


    posted by David on Mar 27, 2009 07:49

    I agree with Jesus.

    Design happends and it's inevitable. If you do not design prior to development, you end up with a bad design.

    Both pictures show exactly this concept applied to UX design: Both screenshots show exactly the same application, with the same style and the same UI interaction. It doesn't matter hoy many makeup layers of fancy UX technologies you apply, the results are always the same app tied to the same design. The old data grids we used to develop back in the old 90s

  • mabra

    RE: Building a Silverlight Line-Of-Business Application – Styling Part 7.1


    posted by mabra on Mar 29, 2009 11:17
    Hi !
    Can you give me possibly a tip? I downloaded the sources, it builds and starts. But I cannot logon [using demo/demo]. In the status bar, there is a message like "please wait, communicating with server" !! Do I use the right user [btw:Wehre is it configured??I was not able to find it!].
    Thanks,
    --mabra
  • -_-

    RE: Building a Silverlight Line-Of-Business Application – Styling Part 7.1


    posted by Damian on Jun 16, 2009 22:14
    I also agree with Jesus. It's like approaching a project without thinking about quality, and after building it saying "ok, let's add the quality now". It has to be an integrated process.

    Anyway, thanks Chris for these Silverlight - LOB series, they're really helpful ;)

    (mabra: try reading the first article of the series, specially "Using the Sample Application")

  • -_-

    RE: Building a Silverlight Line-Of-Business Application – Styling Part 7.1


    posted by Dave Gardner on Jun 24, 2009 06:53
    There's an important distinction that is being missed by Jesus and others here, which is the difference between user experience (UX) design and graphics design. I agree wholeheartedly with the assertion that the design should be done up front - but only the UX design. However, spending too much time on the graphics design up front can in fact have a detrimental effect on the validation/review of that design, as it has a tendency to distract from the UX. The most effective up front UX designs I have seen were produced rough prototype design using tools such Balsamiq or even paper.

    I don't see anything in this article that suggests Chris is saying otherwise. In this article none of the underlying user interactions are being modified. It is, as the title suggests, simply an exercise of styling the application. This is definitely something that can, and in many cases should, be deferred until late in the development process.

Add Comment

Login to comment:
  *      *       

From this series