Docstoc

InterfaceDesign

Document Sample
InterfaceDesign Powered By Docstoc
					Table of Contents



List of Figures ................................................................................................................................................ v
List of Tables ................................................................................................................................................ vi
1      Introduction .......................................................................................................................................... 1
    1.1        Overview of the company ............................................................................................................. 1
    1.2        Purpose of the Report ................................................................................................................... 2
2      Problem Specifications.......................................................................................................................... 4
    2.1        Problem Description ..................................................................................................................... 4
    2.2        Design Constraints and Criteria .................................................................................................... 5
       2.2.1          Constraints ............................................................................................................................ 5
       2.2.2          Criteria................................................................................................................................... 6
    2.3        The Alternatives ............................................................................................................................ 9
       2.3.1          C# .......................................................................................................................................... 9
       2.3.2          IronPython ............................................................................................................................ 9
       2.3.3          Alternatives Not Considered ............................................................................................... 10
3      Evaluation ........................................................................................................................................... 11
       3.1.1          Time to Implement ............................................................................................................. 11
       3.1.2          Time to Modify .................................................................................................................... 12
       3.1.3          Maintainability .................................................................................................................... 13
4      Results ................................................................................................................................................. 15
5      Conclusion ........................................................................................................................................... 16
6      Recommendations .............................................................................................................................. 17
7      Glossary ............................................................................................................................................... 18
8      References .......................................................................................................................................... 19




                                                                                iv
List of Figures



Figure 1.1 AT&T Global Network Operations Center.................................................................................... 1
Figure 1.2 Control System Setup................................................................................................................... 2




                                                                         v
List of Tables



Table 1 Rating Scale ...................................................................................................................................... 7
Table 2 Criteria Weighting ............................................................................................................................ 8
Table 3 Lines of Code of C# vs. Python ....................................................................................................... 11
Table 4 Criteria Scores ................................................................................................................................ 15




                                                                             vi
1 Introduction

1.1 Overview of the company

        Christie Digital is a privately held company that mainly manufactures projectors for use in

cinemas and home entertainment, most notably LCD and DLP projectors. A perhaps less publicly known

product (even to the employees within the company) which Christie Digital manufactures and develops

is used in control rooms. A control room is generally any facility where display technology is being used

to effectively allow collaborating, controlling, monitoring and processing of operations [1]. Installations

of control rooms are normally massive, with a base installation of 16 displays and most customers

installing typically 64-100 displays.




                                 Figure 1.1 AT&T Global Network Operations Center


        As an example, Christie Digital currently provides the display and content management solution

for AT&T's Global Network Operations Center (GNOC) in Bedminster, New Jersey. Figure 1.1

demonstrates the scale and size of a possible control room setup, by showing all the screens that span



                                                        1
the wall. Each screen on the wall must have content published and managed to it via a server. Figure

1.2 below demonstrates the pieces that are involved in a typical control room system (all the pieces are

developed by Christie Digital).




                                       Figure 1.2 Control System Setup


        My role as a visual environments developer was to provide operators of the control room

system an interface for use in managing the content being displayed on the display walls through the

use of client machines. The interface would be in the form of a client side Graphical User Interface (GUI)

and would need to be able to push commands to the server to manage the display wall.


1.2 Purpose of the Report

        The task of developing a graphical user interface during a co-op term was not the standard

maintenance/update work on an existing piece of software but rather was an opportunity to create the

whole client side application from scratch. Since the application would be written essentially from the

beginning with minimal reuse of code, it allowed the team an opportunity to analyze different means of




                                                     2
tackling the problem of providing the customers with an enjoyable experience through the use of new

technologies.


        This report covers the analysis and decisions made in deciding the technology (i.e. language)

chosen by which the GUI was developed for use by the clients. The design criteria, constraints, and

possible solutions are described within the body of the report followed by the recommendation made

and why the recommended solution was chosen opposed to other possible solutions.




                                                    3
2 Problem Specifications

2.1 Problem Description

        Starting in May 2009, the Visual Environments team was tasked with developing a new client

side application for use with the control room systems Christie Digital manufactures. A web based

version of a similar client (WallManager 4.0) was already offered by the company, however customers

demanded more power and usability from the web application; something which could not be provided

through a web client. The company had decided to invest in developing a new client side application and

would appropriately name the new application WallManager 5.0.


        Migrating the application as a web client to a full desktop application allowed the team to start

essentially from scratch as far as the user interface was concerned. The web interface for WallManager

4.0 was implemented in Java; specifically using JavaServer Pages (JSP). Many members of the VE team

had a negative predisposition towards Java. Many of them had learned to program initially on languages

such as C++/C where there is complete flexibility given towards the programmer. Java's approach is

different in that the language attempts offer a restricted environment and force certain design

principles (such as garbage collection, Object Oriented programming) in hopes of developing overall

better performance, ease of use and programs that can be executed on any machine with a Java

interpreter. This dislike towards the current language of choice of the company, set the stage for the

first task of the team; finding a suitable replacement language.




                                                    4
2.2 Design Constraints and Criteria

2.2.1   Constraints

        As with any project in the software industry, the task faced was immediately limited by design

constraints imposed on the team by upper management. Christie Digital has specified the following

technical constraints for the client side application:


1) It must run on the Microsoft .NET framework

2) It must offer all existing functionality of the web client


        Perhaps the largest and most important constraint was that the application developed must

work within the .NET framework. The .NET framework is essentially a large library of classes offered by

Microsoft. The reason for the constraint was that generally when building a user interface it is typical to

initially begin with a GUI toolkit (a set of widgets for use in designing applications). Christie Digital

utilises a specific GUI toolkit that has been written for use within the .NET framework in C#. The

constraint was therefore placed to utilize the same GUI toolkit (thus restricting the team to the

Microsoft .NET environment) to maintain the same look and feel of other applications developed by the

company. The second constraint placed upon the project which may seem obvious, was that any new

application must offer all existing functionality that are offered through the web client. It was important

to emphasise this constraint since it demonstrates that the company was not looking to reduce the

usability of the software in exchange for a sacrifice for performance.




                                                         5
2.2.2   Criteria

        In order to decide upon a language construct to build the new application, the team needed to

decide on factors that would play a deciding role in selecting the new tool of choice. The team would

then go on to use these factors (criteria) during the evaluation of each language for assessment.


Time to Implement


        Although most software developers would love an infinite amount of time to perfect their code,

the time needed to implement a product so that it is stable and polished enough for release is an

important criterion for employers. Perhaps specifically to Christie this criterion is even more important

as they have lagged behind competitors in offering a "fresher" (fast and new) software revision for

controlling their control rooms. This criterion could be affected in a multitude of ways from choosing

different languages to construct the GUI such as tools available to speed up development, and training

in the language if it is unfamiliar to the group members. The simplest way in which languages can be

compared for this specific criterion is with respect to the lines of code needed to perform a similar task.

Although not perfectly accurate, lines of code is a software metric used to measure the amount of time

and effort that will be required to develop a program.


Time to Modify


        During early stages of user interface development, it is important to go through rapid iterations

of possible layouts and designs especially in a company such as Christie where the work model used is

the agile process (rapid iterations). Certain technologies are well suited for rapid designs due to the

nature of the technology itself or through the use of tools available. With a myriad of different

possibilities to compare this criterion, the report will focus on development time related to compilation

time and how the use of tools relating to each recommendation can speed up time to modify.



                                                     6
Maintainability


        In a large scale project, maintainability is crucial to the success of the product. The language

chosen for use in designing user interfaces is important as it must be well suited to be easily modified

and altered without too much investigation of the code. Maintainability is especially important for

companies that hire co-ops/interns since they typically leave the company following their work term.

With developers who are continuously entering and leaving the company writing code for the project , it

places the emphasis that the code written should be easily maintainable. Any language can be written to

maximize its maintainability through the use of editors and proper formatting however certain

languages lessen the burden from the developer by making such things mandatory. Maintainability will

be scaled based on an analysis of readability of each language natively (without the use of an IDE) and

the different means of developing a GUI application using each language.


Rating Scale

        In order to determine which alternative would be the preferred approach for the project; a

rating scale (Table 1) was used in order to add some quantitative results to a qualitative evaluation.


                                                Table 1 Rating Scale

                                Rating                                 Score

                          Equally Preferable                            0

                          Slightly Preferable                           1

                       Significantly Preferable                         2

                           Very Preferable                              3




                                                         7
                                           Table 2 Criteria Weighting

                               Criteria                                 Weighting

                         Time to Implement                                25%

                           Time to Modify                                 25%

                           Maintainability                                50%

                                Total:                                    100%




        For this particular project the above weighting were assigned to the chosen criteria (Table 2).

The weightings were chosen based on an examination of the previous version of the control room

software. For instance, in lieu of Christie Digital not releasing a new version of the software (they do

release updates) for extended periods of time, maintainability was weighted the most in deciding a

language for the project as the team predicted this new version would be in the market for an extended

period of time as well. Finally the remaining two criterion were weighted equally specifically due to the

company's belief in their products (although this may not be the case in every company). Christie Digital

is contempt to add additional time for a specific project in order to complete it to a certain degree of

satisfaction. Knowing perhaps a more flexible deadline for the project is possible if that means

delivering a final better product, the time to implement and modify the application is weighted less than

maintainability. In order to choose an alternative, this report will sum up the weighted scores of each

proposed recommendation and the alternative with the largest positive score would indicate the most

preferable solution.




                                                       8
2.3 The Alternatives

2.3.1   C#

        C# is a language designed by Microsoft, designed to combine the power of C/C++ and the

productivity of Java. C# manages this duality by allowing programmers to essentially turn-off "Java-

esque" features it has implemented(i.e. garbage collection) when they are unwanted and allows

programmers to program using pointers similarly to C/C++. James Gosling who created the Java

programming languages is often quoted for calling C# even an "imitation". C# was developed within

the .NET initiative and is one of the languages designed for the Common Language Infrastructure(CLR).

Languages supported by the CLR are compiled into a Common Intermediate Language(similar to

Bytecode for Java) after which the CIL is compiled per individual system, attempting to follow Java's

motto of "Write once, run anywhere". The CLR is perhaps one of the major draws for choosing any .NET

language (specifically C#), as currently there are over 16 languages that can be compiled into the CIL.

This allows any programmer using any CLR language access to all the libraries and code written in all the

other supported languages. This can be very beneficial for instance since certain languages (such as

functional languages) can solve certain tasks simpler than other and it allows a lot of code reuse

amongst languages. The language is currently in the third release (fourth release in beta) and has been

available since 2000 making plenty of tools available at its disposal.


2.3.2   IronPython

        IronPython is an implementation of the Python programming language on the .NET framework.

To understand the power of IronPython, it is important to take a closer look at the language upon which

it is based: Python. Python is a interpreted scripting language, which means that it too compiles into an

intermediary form prior to being executed on a host CPU. However the major draw to Python, is

perhaps it's dynamic type system. In Python there is no static checking during compilation of variables



                                                     9
such as objects to see if they are properly accessing valid member functions. On the contrary Python

performs dynamic checking during runtime. The way in which Python performs this dynamic check is

often called duck typing and is often quoted with "If it quacks like a duck and looks like a duck, it must

be a duck!". No longer needing to perform a multitude of checks during compilation, development time

is often increased with the decrease in compilation time and code readability is often improved without

the need to perform casts within the code. With a great base to build upon, IronPython enters the

programming language world by offering a .NET implementation of Python. In order to support the new

programming features offered by dynamic languages (i.e. Python), the CLR was extended by Microsoft

in an effort to bring the services needed for a dynamic language.(appropriately named Dynamic

Language Runtime) Since Python is a dynamic programming language it opens up new styles of

programming and brings the power and flexibility of dynamic programming to the .NET platform.

IronPython is being developed by Microsoft and released under Microsoft 's Public License to maintain

the open source aspect of Python. Finally the draw to using IronPython over regular-Python is the

availability of the plethora of libraries associated with the .NET framework, specifically Windows Forms.

Windows Forms is the graphical application programming interface included within the .NET framework.

Allowing use of the API in a dynamic language setting is a huge attraction to many GUI developers.


2.3.3   Alternatives Not Considered

        As one of the design constraints is limiting the project to the .NET framework, any suitable .NET

language (over 20) could utilize the GUI toolkit and could have therefore been considered an alternative.

The reason for so many languages that can be considered is due to the Common Intermediate Language.

Essentially all languages which target the .NET framework compile into the CIL code rather than

platform specific code. This allows any language to easily share libraries/toolkits across themselves. We

had restricted our choices to C# and IronPython however simply because those were the languages that

are well known to the developers on the team.

                                                     10
3 Evaluation

3.1.1   Time to Implement

         Time to implement turned out to be rather difficult to assess as both languages provided

interesting ways to increase productivity and speed up the development cycle. The driving force for C#

for this criteria is the possibility of using Visual Studio. Visual Studio is an Integrated Development

Environment (IDE), which is essentially a tool for developers that allows for code editing, debugging and

designing. Visual Studio contains a GUI designer which allows GUIs to be created without any code

written and allows for designers (rather than programmers) to create the interface without writing any

code.


        IronPython on the other hand is currently not supported in Visual Studio 2008, although future

integration into the IDE is expected as it is a language offered and maintained by Microsoft. Being a

dynamic language it typically requires less code compared to other static languages such as C# to

perform the same task. The best way to illustrate the difference between Python and C# is through the

very simple code fragment below, although the same is true for more complicated programs (Table 1):


                                      Table 3 Lines of Code of C# vs. Python


           A small Hello World App in C#                                       Equivalent in Python

Using System;                                             Class Hello(object):
class Hello                                                   def __init__(self, msg='hello world'):
{                                                                   Self.msg = msg
  private string _msg;                                        def SayHello(self):
  public Hello()                                                   Print self.msg
  {                                                       app = Hello()
    _msg = "Hello World";                                 app.SayHello()
  }
  public Hello (string msg)
  {
    _msg = msg;
  }
  public SayHello()

                                                       11
 {
   Console.Writeline(_msg);
 }
 public static void Main()
 {
   Hello app = new Hello();
   App.SayHello();
 }
}
Lines of Code: 22                                       Lines of Code: 7



        You can see from this example (Table 3) that C# requires a lot of extra code for the sake of the

compiler. The curly braces, semicolons, and type declarations are all line noise and do not add to the

functionality of the program. With a simple example demonstrating a 3:1 ratio of lines of code, it can be

easy to notice that larger projects will benefit from this simplicity and likely take less time to develop

given the lines of code software metric. Dynamic languages also offer the ability to write code using

dynamic programming design patterns which are beyond the scope of this report [3], however it should

be noted that dynamic programming design patterns help solve recurring problems in a simple and

elegant manner. In fact it can be seem that typically when migrating a GUI to a scripting language (such

as Python) the difference code size varied from a factor of 2 to a factor of 60 [4].


        The Visual Environments team however was largely unfamiliar with Python (and therefore

IronPython) and it was expected that the improvements of using a dynamic language would be

neglected and unused. For this reason C# is slightly preferable over Python.


3.1.2   Time to Modify

        Ultimately for this criteria the tools available for each language was the deciding factor.

Although both languages (C# and IronPython) are being developed by Microsoft, IronPython is much

newer. Due to its newness, IronPython is missing the myriad of tools which are available to C#. The most

notable tool at the disposal of C# developers is Microsoft's IDE; Visual Studio. Visual Studio includes an


                                                     12
interface designer to help create graphical user interface applications. The designer can lower the time

needed to modify the interface since changes can be made much faster through a interface designer

than through searching lines of code and playing around with positional values.


        IronPython is expected to be adopted into the Visual Studio environment due to its close

relationship with C#, however this has yet to occur. Where IronPython demonstrates its advantage

however is its nature as a dynamic language. Dynamic languages are successful in a rapid iterative

development environment due to the lack of a compilation phase, a command line interpreter which

allows on the fly changes to the GUI and a reduction in the size of the code allow for modifications in the

program to be implemented and tested much faster.


        Given that code in IronPython is almost transferable to C# since all the .NET calls are the same,

the advantages of using Python for the rapid iterations was very important, especially in the prototyping

phase. Although the lack of a visual designer represents perhaps a slower initial design, modifications

can be made much faster in IronPython which was the point the team was looking to focus on.

Therefore IronPython for this criteria is slightly preferable to C#.


3.1.3   Maintainability

        IronPython is naturally a "cleaner" language [5] due to how it was conceived, forgoing line noise

such as semicolons, curly brackets and type declarations in comparison to C# that cause clutter when

reading. In fact, Python was designed with this initial philosophy of developing a language which was

very clear and readable syntax [6]. Through the loss of this line noise, Python results in code that is

generally much easier to read, refactor and maintain. However it seems the importance on a good IDE

cannot be under emphasised. The ability to perform UI changes through designer allows for code to not

even be read and simply "seen". In fact, the What You See Is What You Get (WYSIWYG) capabilities of

Visual Studio are so simple and in depth that almost all GUI development can be done through the


                                                     13
Visual Editor without seeing an actual line of code. Seeing the final result as you are developing your

code and a strong IDE to manage huge software projects seems to be the greatest advantage that C#

currently offers as it offloads a lot of maintainability from the developer. Regardless whether Python

may have been conceived to be initially "cleaner", once all the tools and IDEs are taken into account at

the disposal of each language (C# and IronPython), C# emerges as being significantly preferable to

IronPython.




                                                    14
4 Results

         Using the rating scale above (Table 1) as well as the weighting table defined above (Table 2) to

interpret the qualitative rating assigned for the criteria we are able to perform a simplistic quantitative

measurable score (Table 3).

                                             Table 4 Criteria Scores

       Criterion                  C#              Weighting            IronPython             Weighting

Time to Implement                  1            1*0.25 = 0.25               0                      0

Time to Modify                     0                    0                   1                1*0.25 = 0.25

Maintainability                    2               2*0.5 = 1                0                      0

         Total                     3                  1.25                  1                     0.25



        With no rating over significantly preferable and many criterion being equally preferable amongst

both alternatives, it is easy to see that the decision is difficult to make with both languages offering

specific advantages and yet being closely intertwined through the .NET framework. The results show

that where IronPython lost the most points was in maintainability in comparison to C#, which was the

heaviest weighted criterion. IronPython suffered in this criterion due to the large lack of tool support,

mainly a proper Integrated Development Environment (IDE) that supports the language. There are

perhaps many criterions that may be deemed missing from the evaluation, however have proved to be

irrelevant. For instance performance and speed of similar programs written in each respective language

are largely similar to the nature of the CLR. Both languages are compiled into very similar Bytecode

regardless of the language they were written in. Choosing one programming language over another is

about balancing criteria, and social factors are always a part of this, however they are hard to perform

analysis on. Forcing a team to use IronPython (or C#) even where it would be appropriate may likely turn

out to be a mistake. Forgoing social factors, overall the evaluation indicate that C# would result in a


                                                      15
better technology to develop the new GUI application on. The language itself was shown to suffer from

a few disadvantages due to the nature of static languages however through the use of the myriad of

tools available, the disadvantages are mitigated for now, resulting in an appropriate language to

develop on.



5 Conclusion

        The results of the evaluation demonstrated the availability of tools at the disposal of a

programming language cannot go understated with results indicating C# to be the decisive

recommended solution in this evaluation.


        Although the design criteria were all equally weighted the circumstances that they were done so

could have been easily changed. For instance had there been a team members who excelled in Python

and none in Python, less importance would have been placed on tools that are of little use. In fact in

practice, choice of language is often decided based on prior working knowledge than on suitability for

the task.


        An interesting study/recommendation would be to perform the same evaluation perhaps in a 1-

3 years. One can expect for IronPython integration into the Visual Studio IDE may be present making

many of the advantages of C# negligible. Similarly due to the development of the Dynamic Language

Runtime (DLR) caused by implemented dynamic languages such as IronPython on the .NET framework,

C# 4.0 new features are expected to include a new dynamic type. This new type will help bring much of

the needed dynamic programming design patterns into C# and perhaps tighten the gap between

IronPython and C#.




                                                    16
6 Recommendations

        The recommendation of the report is to progress forward implementing the new control room

software (WallManager 5.0) using the programming language C#. It is recommended to keep a close eye

on future iterations of the language (specifically C# 4.0 ) in order to perhaps harness future dynamic

type capabilities that will be offered by the language. Development on the software should continue

within the Visual Studio IDE, as it is spectacular environment for developing any Windows Forms user

interfaces and provides excellent support for C#.


        IronPython still remains a viable solution for use in rapid iterative designs for testing due to its

interactive shell which allows changes in the GUI to be made without recompiling the software in cases

where a team member is very proficient in the language. One can never underestimate a programmer's

predisposition towards a programming language (i.e. social factors). Had the majority of the team

enjoyed and liked Java, the new iteration of the software would have most likely been written in Java

(although not JSP) despite negative factors that would deem another language more appropriate.


        Finally it is important to constantly keep in mind that the recommendations and purpose of the

report was in choosing a language for use with the GUI toolkit built upon the Windows Forms API. Much

of the analysis and quite possibly the above recommendation would differ if the purpose of the report

changed.




                                                     17
7 Glossary


Graphical User Interface: (GUI) A type of user interface that allows people to interact with electronic

devices, specifically a computer.



Graphical User Interface (GUI) Toolkit: A set of widgets/classes in a library offered to help with

designing GUIs. Toolkits normally adhere to a unified design which lend themselves in providing a

similar look and feel across applications.



Integrated Development Environment: (IDE) A software application that provides utilities and tools to

facilitate development on a specific language.



Common Intermediate Language: (CIL) An intermediate form which code (within the .NET framework) is

translated to prior to being translated into processor specific assembly.



Visual Studio: An IDE developed by Microsoft. It provides developers the ability to develop console and

GUI applications all for use within the Microsoft sandbox.



WallManager: A program offered by Christie Digital to manage content that is displayed on display walls

used in control room systems.




                                                    18
8 References



[1] Christie Digital Systems, Inc, "Control Room Display Solutions",

http://www.christiedigital.co.uk/NR/rdonlyres/3C9BFF3A-877A-4DE5-BAAB-

B2E7C191B48E/0/ControlRoomBrochure_Jan09_Final.pdf, September 1st 2009


[2] Mads Torgersen , "New Features in C# 4.0", Microsoft White Papers, September 2009


[3] Michael J. Foord. Iron Python In Action. Greenwhich, CT: Manning, 2009, pp 13-50


[4] John K. Ousterhout. "Scripting: Higher Level Programming for the 21st Century," IEEE

Computer magazine, March 1998


[5] Frank Stajano, "Python in Education: Raising a Generation of Native Speakers", Proceedings

of the 8th International Python Conference, Washington DC (2000), pp. 24-27.




                                               19

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:4
posted:7/27/2012
language:
pages:22