A program that creates programs, how to graphically create ... · For example: a window for input,...

A program that createsprograms, how to graphically

create a mobile phoneapplication

Andreas Mettavainio

September 1, 2010Master’s Thesis in Computing Science, 30 ECTS credits

Supervisor at CS-UmU: Lena PalmquistExaminer: Per Lindstrom

Umea UniversityDepartment of Computing Science

SE-901 87 UMEASWEDEN

Abstract

There is pressure on mobile phone application developers. With the success of the iPhone in2007 advanced mobile phones are getting more and more common, and with them a marketfor applications, programs for mobile phones has exploded. The thesis discusses the possibil-ity of helping developers to lift the focus from the code and instead graphically visualize thesystem architecture, the design of graphics and the functionality of the application. First a”proof of concept” program was implemented that allows a user to create the graphics fora mobile phone application using only drag and drop. Then a design proposal was createdwith the goal to allow developers with basic programming experience to create mobile phoneapplications using drag and drop. The proposal was heuristically evaluated with the help ofa checklist consisting of eleven Gestalt laws and ten heuristics that were applied on sketchesof the design proposal constructed in Adobe Photoshop CS4. The results from the two partswere merged. To create applications fast and with low programming experience, using dragand drop is a strong candidate to solve the problem.

Contents

1 Introduction 1

1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Project specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1 The GUIEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.2 The commercial program . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4.1 BlockEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4.2 GUIEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4.3 GUIBlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4.4 NFCBlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4.5 SMSBlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4.6 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4.7 Commercial program or design proposal . . . . . . . . . . . . . . . . . 6

2 Methods and material 7

2.1 The GUIEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Computer Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 The commercial program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1 Heuristic evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.2 The usability principles . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Introducing the commercial program 13

3.1 Design Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.1 The emulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.2 The object window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 Code Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.1 The object window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.2 Background Functionality . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.3 BlockEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3 Aspects not designed for the commercial program . . . . . . . . . . . . . . . . 20

iii

iv CONTENTS

4 Results 23

4.1 The GUIEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1.1 Implemented functionality . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1.2 Considerations and limitations . . . . . . . . . . . . . . . . . . . . . . 26

4.2 Evaluating the commercial program . . . . . . . . . . . . . . . . . . . . . . . 27

4.2.1 Gestalt laws . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2.2 Ten heuristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5 Discussion and conclusions 33

5.1 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.3 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6 Acknowledgements 37

References 39

List of Figures

1.1 Neavas BlockEditor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Time schedule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1 In the beginning of connecting different pages. . . . . . . . . . . . . . . . . . 14

3.2 The ”right” solution to a picture program. . . . . . . . . . . . . . . . . . . . . 16

3.3 Mouse on page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.4 Hand on page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.5 Code Mode overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.6 BlockEditor overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1 Implemented GUIEditor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2 Neavas BlockEditor with connected GUIBlock. . . . . . . . . . . . . . . . . . 25

4.3 Choosing background color in the GUIEditor. . . . . . . . . . . . . . . . . . . 26

v

vi LIST OF FIGURES

Chapter 1

Introduction

Mobile phones are getting more and more advanced. Today a single, average mobile phonehas more computing power than the space shuttle that took Neil Armstrong, Edwin ”Buzz”Aldrin and Michael Collins to the moon in 1969 [6]. Along with these advanced mobilephones a new market has emerged, mobile application shops. In the shops a phone usercan choose from hundreds of thousands of applications to download into his or her mobilephone [1]. As the popularity of the shops increases, so does the pressure on developers tocreate new applications [14].

The goal of this master thesis is to implement a ”proof of concept” program, the GUIEditor,which allows developers to create the graphics for a viable mobile phone application usingonly drag and drop. In addition a design proposal is presented that combines the abil-ity to create graphics, system architecture and functionality for mobile phone applicationsusing only drag and drop. The design proposal for how the commercial program can beimplemented in the future is presented and heuristically evaluated.

1.1 Background

In December 2009 the SATIN project started with the goal to enable end users withoutprior programming experience to create ”their own” mobile services [2]. The three year longproject is a cooperation between people from many different areas of expertise. Partnersassociated with the project are Lulea University of Technology, Umea University, EricssonResearch, TeliaSonera and local small and medium sized enterprises (SME´s). Among theseSME´s are Neava, a company with mobile tele- and data communication as their main focus[16].

This degree project has been produced in collaboration with Neava and advances on theiridea to reduce the workload for mobile phone application developers. Instead of writingall the code for an application, the developer just locates the desirable functionality from alibrary of already implemented functionalities, represented as ”building blocks”. Everyonewill be able to add new blocks, with different functionalities, to the library. When the rightfunctionality is located in the library the developer then drags a block that represents thatspecific function into the program. Each block are connected to all the necessary code thatthe represented function demands, for instance if the application needs the functionality tosend a short message service (SMS). All the developer has to do is to drag the ”SMSBlock”

1

2 Chapter 1. Introduction

into the program and connect it with the correct input and outputs, thus enabling the ap-plication to send a text message. This program, that is named ”BlockEditor”, had alreadybeen implemented by Neava at the beginning of the degree project, see figure 1.1.

Figure 1.1: Neavas BlockEditor.

The BlockEditor contains graphical representations of specific functionalities, called blocks.In figure 1.1 there are two different blocks inserted on the workspace.

– On the left side of the workspace is the NFCBlock inserted.For clarification on NFCBlock see section Terminology.

– On the right side of the workspace is the SMSBlock inserted.For clarification on SMSBlock see section Terminology.

Each block are connected to code that allows their specific functionality to be executed ina mobile phone application.

The BlockEditor enables the developer to lift focus from the code to a higher level. Theshift in focus helps the developer to evaluate the application as a whole. Otherwise, a largeamount of energy is spent on first making each function work by itself, then together withother functions and finally, if time and other resources allow, on the whole application, aproblem common among new developers.

1.2. Project specification 3

The downside with the BlockEditor was its inability to connect a graphical user inter-face (GUI) to the application generated from the editor. The only interface implementedwas a static label with the text ”Hello world MIDlet”. When designing the BlockEditor theability to create graphics had not been prioritized. The BlockEditor was not equipped tohandle different GUI’s, Neava saw this need and the goal for this project was set. A ”proofof concept” program, the GUIEditor, that adds a GUI to the generated application fromthe BlockEditor needed to be implemented. Implementing this ”proof of concept” programwould prove if it is possible to create a GUI using only drag and drop operations and attachfunctionality to it. Another question was if it also proved to be more efficient using drag anddrop than either write the application from scratch or copy and paste code from previousprojects.

1.2 Project specification

This degree project has two main goals. Implementing a ”proof of concept” program,the GUIEditor, and presenting an heuristically evaluated design proposal, the commercialprogram.

1.2.1 The GUIEditor

Neava requested that the GUIEditor should be implemented with the following specifica-tions:

– What the developer describes in the editor is also what is perceived in the mobileapplication.

– The developer should be able to create more than one window that is shown on themobile phone screen.

For example: a window for input, a window for presentation and so on.

– Decide what kind of information that should be presented and also how it should bepresented.

For example: Running text, pictures, tables, diagrams, sound and so forth.

– The editor shall generate code that actualizes the graphical user interface (GUI).

– The GUI generating code shall be represented in the form of building blocks that workwithin the existing prototype environment.

– As long as possible be independent of terminal type, it should work for different mobilephones.

Together with Staffan Johansson, CEO at Neava AB, a final scenario was decided. Theimplemented GUIEditor should be able to create a mobile phone application using onlydrag and drop. The application would send a text message with the collected informationfrom a near field communication tag (NFC-tag) to a mobile phone.

To handle the scenario some specifications need to be fulfilled:

– A mobile phone that supports near field communication.In this case a Nokia 6131 NFC.


– When the mobile phone detects a NFC-tag the following steps need to happen.

1. Graphically ask the mobile phone user where to send the text message.

2. Collect the number given by the user.

3. Send a text message to the specified mobile phone number, with the text collectedfrom the NFC-tag.

1.2.2 The commercial program

In addition to creating this ”proof of concept” program the project would provide a pos-sible solution to how the commercial program can be implemented, graphically, in the future.

At the beginning of this degree project the goal for the commercial program was to enableend users without prior programming experience to create their own applications. Anybodywith an idea and interest in creating applications should be able to use the program. Thegoal soon proved to be too difficult and was revised to a developer with basic knowledge inprogramming, such as understanding input and output and a rough understanding of howthe code is executed.

The design solution was first created and then heuristically evaluated based on a check-list composed in an previous article by the author [15].

The heuristic evaluation would be conducted in the same manner, and with the same check-list, as in the author’s previous article. Sketches of the finished design proposal would beproduced in Adobe Photoshop CS4 and used during the heuristic evaluation of the commer-cial program. For each gestalt law or heuristic in the checklist the evaluator (the author)would thoroughly read the definition. Depending on the character of the current gestalt lawor heuristic used, different parts of the code mode would be evaluated. The main goal foreach evaluation would be to identify usability problems in the design.

1.3 Process

The initial time schedule is shown in figure 1.2. An earlier article composed by the au-thor worked as a base for the degree project [15]. In this article a proposal on how toenable a user to create and manage a system architecture using only drag and drop waspresented. The information gathered for the article combined with the specification givenby Neava provided all the information needed to implement the GUIEditor deignwise. Toactually implement the GUIEditor some research had to be done for understanding the al-ready implemented BlockEditor and how to merge the GUI functionality with the program.

After implementing the GUIEditor a commercial program was created that combined thelearnings gathered up to that point:

1. The BlockEditor provided a way of graphically creating functionality.

2. The author’s previous article provided a solution to creating and managing systemarchitecture graphically.

3. The GUIEditor provided a way of creating a GUI using only drag and drop.

1.4. Terminology 5

Figure 1.2: Time schedule.

The commercial program was designed with pen and paper and the final design proposalwas created in Adobe Photoshop CS4. The Photoshop sketches were then heuristicallyevaluated with the goal to identify possible design flaws.

1.4 Terminology

The following sections describes the terminology used in the thesis.

1.4.1 BlockEditor

BlockEditor is a program implemented by Neava, it was implemented before the degreeproject and is the base of the project. The BlockEditor enables a developer to create thefunctionality of a mobile phone application using drag and drop.

1.4.2 GUIEditor

The GUIEditor has been implemented by the author and is the first goal of the degreeproject. Using drag and drop operations it will create a GUI compatible with the BlockEd-itor.

1.4.3 GUIBlock

A GUIBlock is generated by the GUIEditor and represents the GUI compatible with theBlockEditor and enables the developer to connect input and output between the GUIBlockand functionality blocks such as the NFCBlock or the SMSBlock.

1.4.4 NFCBlock

An NFCBlock represents a functionality that listens for a near field communication (NFC)tag, gathers the information stored in the tag and sends it through its output.

1.4.5 SMSBlock

A SMSBlock represents a functionality that takes two different inputs, the text sent in ashort message service (SMS) and the telephone number which the text message is sent to.


1.4.6 Application

Application refers to the output of the BlockEditor, a mobile phone application.

1.4.7 Commercial program or design proposal

The second goal of the degree project is the design proposal with the task of presenting afuture program that allow developers with basic knowledge in programming to create mobilephone applications using only drag and drop.

Design Mode

Design mode represents a proposal from a previous article written by the author and arepresented in this master thesis. Design mode creates and manages the system architectureof a mobile phone application using drag and drop.

Code Mode

Code mode is a proposal from the author that is presented and heuristically evaluated in thismaster thesis. The goal of the code mode is to represent the functionality of the BlockEditorcombined with the design mode and the functionality of the GUIEditor into one program,the commercial program.

This thesis presents a design proposal that combines the functionalities from the GUIEditor,design mode and code mode into a commercial program, that still has to be implemented.The commercial program will be referred to as either the commercial program or the designproposal in this master thesis.

Chapter 2

Methods and material

This chapter is divided into two parts, first the tools required to implement the GUIEd-itor are presented. The second part is then presented, the tools needed to evaluate thecommercial program, such as how a heuristic evaluation is conducted.

2.1 The GUIEditor

Based on the specifications defined with the help of Staffan Johansson at Neava the GUIEd-itor was implemented. To implement the GUIEditor Microsoft Visual Studio Express 2008and NetBeans IDE 6.1 with JDK 6.0 was used. The implementation of the GUIEditor wasconducted on top of the existing code from the BlockEditor since there was no reason to”invent the wheel again”.

2.1.1 Computer Languages

Computer languages used to create the program:

– C#

– Java and J2ME

– XML

– Json

– CSS

2.2 The commercial program

As a basis for evaluating the commercial program a literature study was conducted. Bothbooks, master’s theses and research articles have been read. To find these texts Googlescholar and ACM databases were used. Keywords for the searches have been; GraphicalUser Interface, interface, design, heuristic evaluation, HCI, HCI design rules, User Interface,UI, Space shuttle, moon, mobile phone computing power and development of websites.Pencil and paper were used in the initial stage of creating a solution to the problem ofcreating a mobile phone application using only drag and drop. Adobe Photoshop CS4 was

7

8 Chapter 2. Methods and material

then used to create sketches of the solution. The reason that some graphics (the emulator)is in the form of an iPhone is not founded on anything else than accessibility for the authorand does not affect the results.

2.2.1 Heuristic evaluation

To evaluate a GUI the field of human-computer interaction (HCI) provides a variety ofmethods. The methods vary from more expensive quantitative methods such as user testingwith a recommended 20 test users [22], to less expensive qualitative methods such as heuris-tic evaluation with a recommended 5 evaluators [18]. Considering the non-existing budgetof this degree project a discount usability engineering method [17] had to be chosen. Thepopular heuristic evaluation method was chosen for its ”quick, cheap, and easy evaluationof a user interface design” [21].

Heuristic evaluation is conducted with the help of a small set of evaluators examining aninterface and judging it against defined usability principles. The goal is to identify usabilityproblems with the design so that the problems can be improved. The usability principlesused in this degree project are a combination between eleven distinct gestalt laws definedby Dempsey Chang, Laurence Dooley and Juhani E. Tuovinen in 2001 and Jakob Nielsen’sten heuristics from 1994 [12][19]. Even though Nielsen’s ten heuristics were defined morethan 15 years ago they are as relevant today as in 1994.

2.2.2 The usability principles

Gestalt is a German word that loosely translates as ”shape”, ”form” or ”figure” [3]. GestaltTheory is a collection of psychological theories that ”provides rational explanations for whyshifts in spacing, timing, and configuration can have a profound effect on the meaning ofpresented information” [11]. As an example, you can look at each frame in a movie sep-arately but it is when you look at all of the frames in a rapid successive order that thefeeling of movement and storytelling appears, the whole becomes greater than the sum ofthe individual parts. This approach to understanding how the human brain perceives visualrecognition has been highly helpful and is often cited in human-computer interaction.

A problem is that there are too many of these theories, or usually they are expressedas laws of Gestalt theory. As early as in 1933 it was stated that there were more than100 Gestalt laws [12]. In 2001 Dempsey Chang, Laurence Dooley and Juhani E. Tuovinennoticed that only a few laws normally apply to visual screen design and wanted to find outif there were any laws overlooked. They identified eleven distinct laws that seemed to sumup all relevant aspects for computer screen design. In the section below both the gestaltlaws and the heuristics are divided into small sections and presented to the reader.

Eleven distinct Gestalt laws for computer screen design

Law of Balance/Symmetry

There needs to be a balance or symmetry in a visual object for it to look complete to ahuman [12].

2.2. The commercial program 9

Law of Continuation

Our brains try to organize everything we see in specific orders to make it easier to perceive.”a Gestalt principle of organization holding that there is an innate tendency to perceive aline as continuing its established direction” [8].

Law of Closure

The human mind perceptually close, or complete, objects that are not complete. For examplea circle that is not completely closed, the human mind automatically perceives as closed.”a Gestalt principle of organization holding that there is an innate tendency to perceiveincomplete objects as complete and to close or fill gaps and to perceive asymmetric stimulias symmetric” [7].

Law of Figure-Ground

We separate background and foreground in a visual field [12]. An example of this is thefamous visual trick where you either focus on the black color in a foreground and two facesappear or focus on the white foreground color and it looks like a vase [24].

Law of Focal Point

Somewhere in the visual presentation there is a point of interest that catches the viewersattention. It can be something emphasized, centered or dissimilar [12].

Law of Isomorphic Correspondence

Because of personal experience all images do not have the same meaning to us. For examplea question mark on a computer screen usually interprets as help and not as a questionbecause of past experience [12].

Law of Pragnanz (Good Form)

Pragnanz is a German word that simply means ”good form”. A simple design or a sym-metrical layout is examples of good form because it can be organized into as good a figureas possible by the observer [12]. The definition of ”good” can mean many things, such asregular, simple, symmetric, and so on, which then refer to specific gestalt laws [5].

Law of Proximity

The human mind perceives a collection of objects close to each other as forming a group. ”aGestalt principle of organization holding that (other things being equal) objects or eventsthat are near to one another (in space or time) are perceived as belonging together as anUnit” [9].

Law of Similarity

As with the law of proximity, objects similar to each other become perceptually groupedby the human mind. ”A Gestalt principle of organization holding that (other things beingequal) parts of a stimulus field that are similar to each other tend to be perceived as belongingtogether as an Unit” [10].


Law of Simplicity

Humans always unconsciously try to simplify what is visualized into something that isunderstandable. Problems can occur if the visualization is too complex or cluttered, thenthe simplification can represent something different than the visualization.

Law of Unity/Harmony

If related objects do not appear in the same formation, the user perceives the separate objectsas not being part of the main visual design. ”Unity implies that a congruity or arrangementexists among the elements in a design; they look as through they belong together, as thoughthere is some visual connection beyond mere chance that has caused them to come together”[13].

Ten Usability Heuristics

After collaboration between Jakob Nielsen and Rolf Molich in 1990 a list of heuristics (us-ability principles) was developed. In 1994 Nielsen presented a revised set of ten heuristicsthat is as relevant today as when they were presented more than 15 years ago [19].

The author’s checklist for evaluating the commercial program consists of the above definedGestalt laws combined with the following ten heuristics:

Visibility of system status

Users should always be updated about the current status of the system. The system shoulddisplay appropriate feedback within a time period that keeps the user in context. ”Thesystem should always keep users informed about what is going on, through appropriatefeedback within reasonable time” [19].

Match between system and the real world

The system should present information with real-world examples. For example a folder iconrepresents a collection of different data types. ”The system should speak the users’ language,with words, phrases and concepts familiar to the user, rather than system-oriented terms.Follow real-world conventions, making information appear in a natural and logical order”[19].

User control and freedom

Users should always be presented with the option to undo or redo the last operation. ”Usersoften choose system functions by mistake and will need a clearly marked ”emergency exit”to leave the unwanted state without having to go through an extended dialogue. Supportundo and redo” [19].

Consistency and standards

Consistency and standards prevent user confusion and allow the user to apprehend a new sit-uation more rapidly. ”Users should not have to wonder whether different words, situations,or actions mean the same thing. Follow platform conventions” [19].

2.2. The commercial program 11

Error prevention

The system should minimize possible user generated errors with careful design which pre-vents error generating actions. ”Even better than good error messages is a careful designwhich prevents a problem from occurring in the first place. Either eliminate error-prone con-ditions or check for them and present users with a confirmation option before they committo the action” [19].

Recognition rather than recall

Making objects, actions and options visible for the user reduces the amount of informationhe or she has to manage and consequently the work load. ”Minimize the user’s memoryload by making objects, actions, and options visible. The user should not have to rememberinformation from one part of the dialogue to another. Instructions for use of the systemshould be visible or easily retrievable whenever appropriate” [19].

Flexibility and efficiency of use

A novice user needs more information and pointers than an expert user. To prevent thatthe expert user experiences the system as time consuming and inefficient, accelerators canbe implemented. Common accelerators are keyboard shortcuts that executes operationswhen the user combines different key strokes. For example pressing the Ctrl- and z-keyssimultaneously would undo the last operation. ”Accelerators – unseen by the novice user –may often speed up the interaction for the expert user such that the system can cater toboth inexperienced and experienced users. Allow users to tailor frequent actions” [19].

Aesthetic and minimalist design

An aesthetic and minimalistic design helps the user find relevant information, as opposed toa cluttered design. ”Dialogues should not contain information which is irrelevant or rarelyneeded. Every extra unit of information in a dialogue competes with the relevant units ofinformation and diminishes their relative visibility” [19].

Help users recognize, diagnose, and recover from errors

The system should present error messages in plain text without error codes. An errormessage in plain text that explains the problem and suggests a solution is preferred to nonexplanatory error codes. ”Error messages should be expressed in plain language (no codes),precisely indicate the problem, and constructively suggest a solution” [19].

Help and documentation

Help and documentation should give proposals that are relevant to the current context andnot overwhelm the user with information. ”Even though it is better if the system can beused without documentation, it may be necessary to provide help and documentation. Anysuch information should be easy to search, focused on the user’s task, list concrete steps tobe carried out, and not be too large” [19].

Chapter 3

Introducing the commercialprogram

As mentioned above, this project approaches the problem of how to enable a developerto create, manage and visualize a mobile phone application using drag and drop. Thecommercial program is divided into two parts, first the design mode which was created andevaluated in the author’s previous article [15]. The second part presents the continued work,the code mode, this is also the part that is heuristically evaluated in this degree project.Before designing the commercial program, three main areas of interest were defined.

1. To be able to communicate with the application there is a need to create and managea GUI.

A solution to this is implemented and presented under chapter Results, calledGUIEditor.

2. The developer needs to be able to create and manage the system architecture.

A solution for this problem is presented in the author’s previous article andforms the basis for the commercial program [15].

3. The ability to add functionality to the applications.

How to add functionality to the applications is presented in this section andwill be heuristically evaluated under chapter Results, as part of the commercialprogram.

Item 1 and item 2 are already presented, to complete the commercial program item 3 needsto be introduced, the ability to add functionality to each frame in the application, also calledthe code mode. A frame is a specific screen inside the application. Four specific functionalitysituations were recognized during the implementation of the GUIEditor in addition to thoseimplemented by the BlockEditor and has to be solved by the code mode.

1. Functionality (or code) running in the background.

2. Code running in the background calls on the GUI.

13

14 Chapter 3. Introducing the commercial program

3. The GUI calls on the code running in the background.

4. The GUI calls on the code running in the background and expects an answer.

– All of the code should be able to run in parallel and synchronized.

The design mode is evaluated in the author’s previous article and presented below to intro-duce the commercial program.

3.1 Design Mode

In figure 3.1 there is one large iPhone emulator to the left, and ten smaller iPhone emulatorresembling objects to the right within a window. Each screen of the emulator objectshas a numbered background ranging from 1 to 10, representing ten unique frames in theapplication to be created. As seen in figure 3.1 the large emulator is marked with thenumber 1, the same number as the object in the top left position. The same backgroundsand the fact that the object is highlighted indicate that application frame 1 is selected andrepresented in the emulator.

Figure 3.1: In the beginning of connecting different pages.

3.1. Design Mode 15

3.1.1 The emulator

The emulator has an important role in the program. It enables the developer to eithercreate/change the GUI for the selected frame or create a link to another frame. An emulatorhas one major advantage, it simulates a mobile phone on a computer. This enables thedeveloper to test the application on the computer instead of loading it to the mobile phoneand loosing valuable development time. The idea behind providing an emulator in thecommercial program is, besides the advantage to test the application on the computer, toallow the developer to change the application in the emulator and get feedback directly.Hopefully the developer will perceive the idea of ”what you see is what you get”. Below issome functionality that the emulator handles.

Edit the GUI

If the developer chooses to edit the GUI, the first step is to enter the ”edit GUI mode”.How to enable this mode has yet to be implemented. Once it has been enabled the emulatorgrows in size and becomes centered on the screen, the window containing all the objectsdecreases in size and moves to the right and out of focus for the user. The developer isthen presented with a library of ”blocks” that he or she can drag into the emulator andmodify. If no ”block” is to satisfaction the option to create a new ”block” is available forthe developer.

Create a link to another frame

If the developer instead chooses to create a link between two frames he first has to verifythat the selected frame is the right one to start the link from. The interconnection betweentwo frames is created in the following steps:

1. From the object window, choose the frame which the link connects from.

This highlights the selected frame in the object window, see figure 3.1.

2. In the emulator, choose which button in the frame to implement the change to anotherframe.

This highlights the button with a red color, see figure 3.1.

3. From the object window, choose the frame which the interconnection connects to whenthe button is pressed.

This creates an arrow between the two frames, pointing to the last selectedframe, see figure 3.2.

– Optional: Double clicking on the arrow displays the possibility to change color andother attributes to help the developer keep it organized when multiple connectionsclutters the object window.


Figure 3.2: The ”right” solution to a picture program.

3.1.2 The object window

The object window allows the developer to create and manage, but also to visualize theapplications system architecture as seen in figure 3.2. The developer can rearrange theemulator objects as it suits him or her by simply clicking on any of the objects and draggingand dropping them anywhere in the window. In figure 3.3 there is a mouse arrow hoveringframe number 3. If clicked and dragged frame 3 would move to any location that thedeveloper chooses to drop it on. If an object is dragged and also has been linked earlierthe colored arrow simply continues to attach to the object even when moved. The objectwindow allows for the developer to move and change size according to specific needs. Ifthe window’s title bar is double clicked it assumes the default size and position as seen inthe figures. Functionality of the object window is described in more detail in the followingsubsections.

Zooming in and out

If the application increases in size and more and more objects are added to the object windowthe developer would need to zoom in and out to get an overview of all of the application’sframes. This is done by using the scroll wheel located on a computer mouse. The developerensures that the arrow is over the object window and scrolls forward to zoom in or backwardto zoom out. The focus when zooming in would be determined by the location of the arrow.In figure 3.3 for example it would zoom in on frame 3, when zooming out the focus wouldbe the center of the object window.

3.2. Code Mode 17

Figure 3.3: Mouse on page.

Panning horizontal and vertical

As seen in figure 3.3 the rightmost object seems to be cut in half. The reason for this isthat the object window is implemented like a real window. Imagine that the background ismuch bigger than the object window, actually there are 3 more objects to the right of the”half” object rightmost in the window. The object window displays only a small part of thewhole background, just like a real window. If the developer would like to work with themhe would either have to zoom out or he could move to the right. First he or she ensures thatthe arrow is not hovering over any object and moves it if that is the case. A hand appearswhen not hovering over any object as seen in figure 3.4. Click and the hand ”grabs” thebackground and if moved to the left the objects on the right appear and the objects on theleft disappear.

3.2 Code Mode

Code mode is the mode the developer enters when he or she wants to implement functionalityto the application developed in the commercial program. Functionality for the graphics,frames and background functionalities are created here. When pressing the code modebutton the emulator disappears by moving outside of the main window. The object windowmoves to the latest position in code mode, in this case in the bottom left corner as in figure3.5. The arrows representing the linking between frames is blurred so the user can still seethe system architecture but not edit it. A new window appears representing the background


Figure 3.4: Hand on page.

functionality (code running in the background).

3.2.1 The object window

The object window still presents all the frames implemented in the application. When incode mode it changes two main parts. First the arrows representing the system architectureare blurred so the user is still able to see the layout but get the feeling he or she cannot editthe system architecture. The second part introduces the code icons, these are icons thatare meant to represent implementation of code. In figure 3.5 there are two frames that hasfunctionality attached to them, the frame on the top and the second frame from the leftfurthest down.

3.2.2 Background Functionality

To be able to have code running in the background of the application and allow for the GUIto communicate with it a new window had to be implemented. This window represents allthe functionality that is running in the background of the application and not dependenton the GUI. The background functionality window is placed in the upper right corner infigure 3.5. When holding the mouse pointer over one background functionality, all codeicons connected with the input or output of the functionality is highlighted, both in thebackground functionality window and in the object window. Each background functionalitygets a ranking based on where in the list they are placed, a higher position means that

3.2. Code Mode 19

Figure 3.5: Code Mode overview.

the application prioritizes the functionality during runtime. The position on the list isdetermined by the developer, the higher on the list the higher the commercial programranks the functionality.

3.2.3 BlockEditor

With Neava’s implemented program as a base, the design on how to allow for a user to addfunctionality began. As seen in figure 1.1 the problem on how to connect different blockswith each other to create a more sophisticated output had been solved.

In figure 1.1 there are two different objects that have been dragged into the workspaceand connected to each other, from left is first the NFCBlock and then the SMSBlock. TheNFCBlock’s Payload output, the text stored inside the NFC tag, are connected to the SMS-Block’s PayloadText input, the text placed in the text message. In the SMSBlock’s Numberinput is the telephone number the text message will be sent to hardcoded.

The problem that had to be addressed was enabling a logical way for the user to connectinput and output between these blocks and the graphics of other frames or even backgroundfunctionality. The author’s proposal to this problem was to create an additional window,that activates when the user double clicks on a code icon in the object window or in thebackground functionality window as seen in figure 3.6. On the furthest to the left of theBlockEditor there are blocks that the user can drag into the center and connect with other


blocks, thus creating the functionality for the application. To connect input and output tothis functionality two fields were inserted. On the left side the inputs were placed repre-sented by a large green arrow, and similar with the output on the right represented by alarge red arrow as seen in figure 3.6. In this example only one input from a backgroundfunctionality has been attached as seen on the input field under the Background Function-ality where one NFC input is represented as a rectangle with dark background color androunded corners. The NFC input has been connected by dragging the rectangle over one ofthe blocks that has been dragged into the center, in this case a NFCBlock. The NFCBlockhas also connected its output with a SMSBlock’s input and functionality has been created.This specific functionality waits until a NFC tag has been recognized by the application(which is done in the background functionality) and calls on the NFCBlock which extractsthe information stored in the NFC tag and sends it as a text message to a specific mobilephone number. To arrange and zoom in and out the same tactics as in the object windowin the design mode is used.

Figure 3.6: BlockEditor overview.

3.3 Aspects not designed for the commercial program

Aspects not presented in the commercial program sketches are listed below.

– The ability to switch to ”edit GUI mode”.The idea was to add a version of the GUIEditor into the design proposalthat allow developers to create graphics for future mobile phone applications.

3.3. Aspects not designed for the commercial program 21

This implementation was not prioritized when time was of the essence, besidesare the GUIEditor already presented in this thesis. The only loss is a soluti-on on how the GUIEditor can be implemented into the commercial programlogically for the developer.

– The option to create a new emulator resembling object inside the object window.Perhaps this should also include given default objects that can be edited for timeoptimization.

Also not prioritized due to lack of time.

Chapter 4

Results

4.1 The GUIEditor

Based on Neavas already implemented BlockEditor and the projects goal to connect a GUIto the functionality of the program, the work begun. To make sure it was possible to im-plement a program that could create and manage a GUI using only drag and drop the firststep was to create a ”GUIBlock”, a block that would create a GUI for the application whencompiled. This block was created and used as the other blocks, with the difference of itmanaging the graphics while the other blocks were concentrated on creating functionality.With the help of an Open source JavaME UI framework and some editing in the BlockEdi-tor a GUIBlock was created. The GUIBlock supplies a background for the application andshows a popup window when a NFC tag has been read by the application. In this popupwindow the user can insert a mobile phone number and send the information collected fromthe NFC tag as a text message.

With a tested GUIBlock that fulfills the degree project goal of sending a text messagewhen reading a NFC tag it was time for implementing the GUIEditor. With the infor-mation gathered from the author’s previous article, the goal of creating graphics with anemulator and the ”what you see is what you get” mentality was set. To create a GUIBlockthe user drags graphical objects representing specific graphical functionality into an emula-tor and automatically sees in the emulator what the application looks like in a real mobilephone, as seen in figure 4.1.

To avoid ”inventing the wheel again”, the code from the BlockEditor was reused. An imageof a mobile phone, a Nokia 6131 NFC used to test applications with, was implemented withthe same pixel size on the image screen as it has in real life, 320 x 240 pixels. In thisscreen the user can drop representations of the dragged graphical functionality written inC# which has a connection to the J2ME, XML and css code needed to create the specificgraphical functionality in the mobile phone.

When pressing ”compile” in the GUIEditor, it looks at which graphical objects that hasbeen dragged into the emulator and combines the connected code into a GUIBlock. ThisGUIBlock can then be used in the BlockEditor, the user drags in the GUIBlock with otherblocks providing wanted functionality, connects the different blocks and when pressing thecompile button, a working jar file is produced that can be used inside a mobile phone, as

23

24 Chapter 4. Results

Figure 4.1: Implemented GUIEditor.

seen in figure 4.2.

4.1.1 Implemented functionality

The GUIEditor implements an emulator that allows the user to see on the computer screenwhat the application looks like in a mobile phone. Two graphical objects, each representinga graphical functionality has also been implemented. The only graphical object that wasprioritized to implement was the PopupNumber, it would not be possible to create the sce-nario specified in the beginning of the master thesis without it. BgPicture was implementedto control the GUIEditor would handle multiple graphical objects and to decorate the oth-erwise empty background.

The first object represents a background picture, named BgPicture. When BgPicture isdragged into the screen, a default picture is shown. If another picture is more desirable, allthe user has to do is to double click on the inserted object and the option to choose another.png image is displayed. As seen in figure 4.1 multiple BgPictures can be dragged into theemulator. Each inserted BgPicture can be placed anywhere the user desires to move it onthe emulator screen. The position of each BgPicture will be displayed in the mobile screenat the corresponding position, see figure 4.1.

The second graphical object represents a popup window, named PopupNumber. The object

4.1. The GUIEditor 25

Figure 4.2: Neavas BlockEditor with connected GUIBlock.

is selected and highlighted in figure 4.1. The user drags PopupNumber into the emula-tor screen and a popup window with the static text ”Input Number:” is displayed. Thisobject can also be dropped in any location on the emulator screen and displayed at thecorresponding position in the mobile phone screen. The user can edit the size of an insertedPopupNumber by dragging one of the sides of the popup window, the same functionality canbe found in ordinary computer windows. The popup window is not displayed on applicationstartup as in the case of BgPicture objects. It is activated and displayed in the applicationwhen needed, for instance if a NFC tag is detected and needs a telephone number. Whenthe popup window activates is determined by connecting the GUIBlocks ”PopupNumber1”output to a suitable input in the BlockEditor, as seen in figure 4.2. When activated in themobile phone application the input box catches the number to which the text message issent by listening on keystrokes on the physical mobile phone.

The option to change the application’s background color has also been implemented. Theuser simply presses the ”Change background color” button and a color palette is displayed,see figure 4.3. When the user feels that the graphics for the program is completed he orshe presses the ”Compile” button and the GUIEditor automatically checks which and howmany graphical objects that has been dragged into the screen, collects the code connectedto each object and combines them into a GUIBlock. This GUIBlock can then be used inthe BlockEditor and an application with a GUI can be created.


Figure 4.3: Choosing background color in the GUIEditor.

4.1.2 Considerations and limitations

Implementing the GUIEditor was conducted in small steps to ensure progress, first a GUIBlockthat worked with the BlockEditor was created manually. When the GUIBlock finally wasshowing a GUI in the application none of the functionality was working, the application didnot detect any NFC-tags. The problem was solved by dividing the GUI to an own thread andthus enabling the application to show graphics (GUI-thread) and at the same time listeningafter a NFC-tag (Functionality-thread). When creating a GUI-thread the BlockEditor itselfneeds to write J2ME code that enables communication between the threads. Fortunatelythe BlockEditor already had this implemented, it writes J2ME code that handles the com-munication between different functionality blocks input and output. The GUIBlock coulduse the same part of code with some tweaks to enable communication between the twodifferent threads.

A limitation that only allows one GUIBlock at a time to be dragged into the BlockEdi-tor workspace was implemented. The application is only meant to show one frame withdifferent graphical objects to reduce the complexity of the implementation. This limitationis done by comparing the name of each block dragged into the workspace to ”GUI” withcapital letters. If an additional GUIBlock is dragged into the workspace a label with thetext ”Please remove inserted GUIBlock before inserting a new GUIBlock” is presented, inaddition the dragged GUIBlock are not allowed to be dropped on the workspace.

4.2. Evaluating the commercial program 27

When a GUIBlock is dragged into the workspace it will be placed on a higher level andcentered above the other functionality blocks, as seen in figure 4.2. The reason for thisseparation is that the functionality blocks are executed sequential from the left, and theGUIBlock needs to communicate with any block despite its placement on the workspace.Placing the GUIBlock centered above the functionality blocks allows it to connect to afunctionality block without the line representing the connection crossing over an unrelatedfunctionality block.

The GUIEditor was first supposed to be implemented with the help of a real emulator,with the advantage of executing code that displays the graphical objects on the computerscreen as they would appear on a mobile phone. This solution proved to be too compli-cated and was replaced with displaying an image of a mobile phone. The GUIEditor wasimplemented by editing the existing code from the BlockEditor with an image of a mobilephone, a Nokia 6131 NFC, in the middle of the GUIEditor workspace. A disadvantageusing an image instead of a real emulator is that each graphical object needs to be createdmanually with the help of XAML and C#. Even though the graphical object are loadedinto the GUIEditor automatically when the finished XAML and C# files are placed in aspecial folder, there are no easy task to add new graphical objects to the GUIEditor. Es-pecially when the code (J2ME, CSS and XML) that executes the graphics the graphicalobject represents in a mobile phone needs to be connected. The different codes are storedin XML files because it is quite complicated to compile the J2ME, CSS and XML code. Forexample the placement of PopupNumber is decided in the CSS code. First the placementof the graphical object representing the PopupNumber needs to be collected, then the CSScode needs to be read, altered with the new value for x and y and saved. The GUIEdi-tor opens the XML file representing the CSS code and searches for a row that has replacedefined as ”repX”, if found, ”repX” is replaced with the new value for x. This solutionworks for the two implemented graphical objects, and are implemented to be as generalas possible, but there are no guarantee it will work when implementing new graphical ob-jects. In future versions of the GUIEditor the current solution on how to represent and editthe code needs to be addressed. Unfortunately, no better solution were found by the author.

The ability to edit graphical objects hidden behind other graphical objects on the workspaceneeded to be made available for developers working with the GUIEditor. This option are notimplemented in the current version of the GUIEditor but are meant to work as the function”layers” that can be found in Adobe Flash and Photoshop development environments. Thedeveloper chooses which layer an object will be inserted into, the different layers can bethought of as a list of layers, the higher on the list a layer is placed the higher level willthe graphical objects linked to the layer be presented on. For example graphical objectsinserted into the layer highest on the list will lie on top of all the other objects insertedinto lower placed layers. To access a hidden graphical object the developer hides the layerscontaining objects preventing accessibility. To hide layers the developer only checks the”hide layer option” for each layer, granting access to hidden graphical objects without theneed to rearranging any of the obstructive objects.

4.2 Evaluating the commercial program

The result is divided according to the checklist and in each subsection there is a shortdiscussion on how well the author’s solution is consistent with the current law or heuristic


that the subsection is representing.

4.2.1 Gestalt laws

Law of Balance/Symmetry

The fact that the background functionality window is smaller than the object window indi-cates that it is of smaller significance. Both windows are of great importance but the feelingthat the background functionality window is an addition to the object window helps theuser to see it as an additional help rather than the main task when creating an application.

Law of Continuation

The BlockEditor provides good continuation when inputs are on the left side of where thefunctionality is created and output is on the right. This helps the user to get a feeling ofcontinuation because of the information passing from left to right, the same format as whenreading a text and thus providing a familiar setting.

Law of Closure

The presented design proposal, the commercial program, does not contain any incompleteobjects or gaps that allows the viewer to perceive them as closed or filled. Only the groupingof different blocks come close to this. And it depends on how the developer chooses to arrangethem. In addition, when the blocks are linked together, a sense of grouping is achieved.

Law of Figure-Ground

One advantage of having the different parts of the code in different windows is that the userknows what each window is supposed to do. Instead of combining all of them and makingthe proposal much more cluttered.

Law of Focal Point

The natural focal point in the commercial program is the object window, partly becauseit is usually cluttered with details, the emulator resembling objects. But also because theobject window takes up more than half of the whole commercial program’s width. If theBlockEditor window is activated it becomes the natural focal point since it takes up mostof the view in the commercial program and is positioned on top of all the other windows.Thus enabling the developer to focus on the current task of adding functionality to theapplication. An issue with the BlockEditor’s positioning is that it conceals the developer’soverview of already implemented functionality.

Law of Isomorphic Correspondence

The program assumes that the users are familiar with the ranking of layers from programssuch as Adobe Photoshop or Flash where the layer at the bottom of the list of layers iscovered by each layer above it, the same ranking is done with the background functionali-ties. The higher on the list of functionalities the higher the application will prioritize eachfunctionality during runtime.


Law of Pragnanz (Good Form)

The design of the program is simple, and the layout can be really symmetrical as in figure3.5. The problem is that how symmetrical the layout becomes depends on the developer. Itis not a big or time consuming job to rearrange the emulator resembling objects or the blocksso that the developer has a helpful overview of the system architecture or the functionality.But will he or she do the job?

Law of Proximity

The proximity between the emulator objects and the blocks lets them be perceived as aunit.

Law of Similarity

Each of the windows has similar objects inside of them. The background functionalitywindow have similar background functionalities with the only difference in the name andranking of each window. The same is for the BlockEditor where each block has the sameform with the exception of number of input and outputs and the icon representing the block.

Law of Simplicity

At a first glance the program seems to be really simple. Its use is quite simple, when thedeveloper becomes familiar with the program. But, there is nothing in the design thatgives obvious clues of the usage. In figure 3.6 the large green and red arrows assist inunderstanding the functionality of the frame. Green arrows represent the frame’s differentinputs; graphics, frames or background functionality, and red arrows represent the differentoutputs. A problem is that the developer needs to understand how to connect input andoutput to the frame. In the example of figure 3.6 a background functionality is connectedto the frame’s input. For a developer it is not obvious that he or she should drag desiredfunctionality from the background functionality window and drop it on the desired framein the object window.

Law of Unity/Harmony

One problem with the BlockEditor is that it is so large that the user looses the overview of theprogram, it does not indicate which code icon the open BlockEditor window is representingand the user has to minimize the window for an overview of the system.

4.2.2 Ten heuristics

Visibility of system status

The program gives some amount of feedback, for example it highlights the selected code iconin the object or background functionality window. The arrows connecting emulator objectsin the object window give the user an overview of the system architecture. On the downsidethe program gives the user no feedback on how to arrange the blocks or the backgroundfunctionality items and zoom in and out in the BlockEditor window other than the mousechanging between an arrow when over a block and displaying a hand when the mouse ishovering over the BlockEditor window background.


Match between system and the real world

There is a match between the system and the real world with the help of the emulatorobjects resembling an iPhone. The user is informed that the program handles somethingwith regards to a mobile phone. However, what it handles is not as obvious. A flow chart is aconventional way of describing the flow of a system with the help of arrows, for example witha Unified Modeling Language (UML) diagram. This gives an experienced user a familiarunderstanding for the system architecture and the system functionalities found in each codeicon and presented with the BlockEditor window.

User control and freedom

The system does not support undo and redo except for the option to close blocks by hittingthe red ”X” marked button on the upper right side of each block.

Consistency and standards

The program takes advantage of the standardized Microsoft windows that almost everycomputer user is familiar with. This gives the user a familiar setting and introduces moreoptions under the menu bar.

Error prevention

To visually create functionality between frames and background functionalities reduces theerror rate rather than writing it in pure code. It allows the user to use already tested codeand concentrate on connecting the blocks with the right input and output.

Recognition rather than recall

The way this program visualizes the system architecture gives the user visible and easilyretrievable information about the application being created. A possible problem is thatthe program does not visualize how the user creates functionality between two frames orbackground functionalities. Instead he or she has to know it by heart.

Flexibility and efficiency of use

The only implementation that comes even close to being an accelerator in the program isthe ability to zoom in and out with the help of the scroll wheel, a function often used andfor an experienced user almost obvious, but the program is designed with the expectationthat also a novice user uses that function.

Aesthetic and minimalist design

The current revision of the program contains a minimal amount of text. The reason forthis is when testing if the design is user friendly, it is preferable if the user can manage theprogram without the use of explanatory text. The ultimate design needs no text, the userunderstands the program only by looking at it. But that is almost never achieved and adesign can easily raise the usability with the help of explanatory text when needed. Theprogram design is as minimalistic as possible to avoid getting the user confused by irrelevantinformation.


Help users recognize, diagnose, and recover from errors

In the current design of the program no implementation of error handling has been done.It is something that has to be addressed in a future revision.

Help and documentation

In the current design of the program no implementation of help and documentation hasbeen done. It is something that has to be addressed in a future revision.

Chapter 5

Discussion and conclusions

The author’s design proposal to the commercial program stands up against many of thelaws and heuristics but fails when it is time for a user to start using the program. There areno signs in the design that give away how it is supposed to be used. This is a problem thatoccurs for first time developers but then disappears over time when he or she has used theprogram a couple of times. Perhaps the option of playing a short instruction video couldbe implemented. Then it would be up to the developer if he or she would appreciate somehelp. There is always the option to insert instructions in the program that explicitly explainhow to use the program. But that could distract and become tiresome when the developerbecomes familiarized with the program.

To zoom in/out and move either an emulator object or the whole background inside theobject window are common features today, and are assumed that the developer can handle.

The implemented GUIEditor and BlockEditor manage to create the scenario specified inthe beginning of this thesis and they cut development time dramatically for a developerfamiliarized with them, such as the author.

This answers the questions defined in the beginning of the degree project. It is possibleto create a GUI and attaching functionality using drag and drop. It is also more efficientwith shorter development time and the risk of implementing wrong or bad code reduced. Aproblem is that the GUIEditor and the connection between the GUIBlock and the BlockEd-itor are implemented to manage the scenario specified in the beginning of the thesis. Itworks for this specific scenario with few blocks and is implemented to be as adaptable andgeneral as possible but there will be trouble in unforeseen situations.

These facts lead to the conclusion that there was no reason to evaluate how user friendly theimplemented GUIEditor is. Especially when it is implemented as ”proof of concept” and nospecial attention has been directed to create a user friendly program. The focus should in-stead be on a new, user friendly, program design that allows developers to create applicationsusing this new way of developing applications, such as the commercial program. Instead ofrealizing an expensive quantitative evaluation with non existing resources it seemed morerelevant to present a solution for how the program could be implemented in the future.The implementation of the GUIEditor proves that it is possible to do and is a real solutionto developing mobile phone applications using drag and drop. Even though the GUIEditor

33

34 Chapter 5. Discussion and conclusions

is not perfect it has given viable insight into the problems of creating a drag and drop editor.

There needs to be a way of accessing the code directly through the program so that ex-perienced programmers can change the code to get an application that behaves exactly asthey want. How will the screening process for adding blocks to the public library be con-ducted, if one block contains damaging code, who is responsible? A possible solution to thisis to copy Wikipedia, an Internet site filled with facts that are edited by the readers [4].If the developers are aware that it is a public project that can contain corrupted code andthey use blocks with care and remove suspicious ones it could work.

A reflection in regards to the commercial program has arisen, it could possibly be a goodidea to combine the two parts of code mode and managing the system architecture. Ba-sically they do the same thing, making connections between objects. If functionality andinterconnection between two frames could be displayed by the same arrow the programwould be less cluttered. Basically all the connection between two frames would go throughone arrow that splits in the ends into the two input or outputs; graphics and frames.

There are a lot of problems that have to be addressed but as a solution to creating ap-plications faster and with low programming experience I believe it is the way to go.

Thanks to the insight given from the implemented GUIEditor a viable solution, the commer-cial program, has been presented. It is not a finished solution but it is a working concept.Considering there is an ongoing project [2] with far more resources (users, companies andmoney) that to date has not presented a final evaluated solution the outcome of this degreeproject is as expected. Nothing is obvious in this new way of looking at programming.However, this thesis presents a qualified proposal that should be taken into considerationand be thoroughly evaluated.

5.1 Restrictions

To implement the GUIEditor took much longer than calculated. This meant that designingthe commercial program got less time than calculated since the main task for this thesiswere to create a ”proof of concept” program which enables users to create applications usingonly drag and drop. The GUIEditor still contains multiple known bugs, but as a ”proof ofconcept” program it is acceptable since it manages to create the scenario specified in thebeginning of this master thesis.

5.2 Limitations

The author’s choice of evaluating the commercial program with only one evaluator (theauthor) is a cause for discussion. Nielsen states that ”one person will never be able to findall the usability problems in an interface” [18]. Meanwhile he also states that ”As soon asyou collect data from a single test user, your insights shoot up and you have already learnedalmost a third of all there is to know about the usability of the design. The differencebetween zero and even a little bit of data is astounding” [20]. The presented solution isin no way finished and has to be implemented and thoroughly tested before any user hasany use of it. However, in the beginning of the design process when nothing has beenimplemented this way of evaluating the design can be valuable. Still, almost a third of all

5.3. Future work 35

the usability can be learned and the checklist provides a sense of security that the evaluatorhas not missed anything basic in the design. It also saves the designer/evaluator time whenhe or she can evaluate the design in their mind with help of only a couple of rough sketches.

5.3 Future work

The author’s solution is a good foundation but is by no means finished. Besides small prob-lems such as changing the background color of the object window, more serious problemshave to be addressed. Is the design intuitive enough so that a first time developer can startusing the program, which kind of pointers does he or she need? This evaluation has beenvaluable since many problems with the design have come up. For the more experienceduser accelerators have to be implemented, as a suggestion the user could be able to mark acouple of frames and copy-paste them. Thus adding a whole new set of frames to the objectwindow, with the option to edit each frame for their purpose. Another function could allowthe developer to only create two frames and then the program would repeat itself until adesired number of frames is reached. These examples were noted thanks to the evaluation.The design does not handle any repeat operations, something that would be valuable whenfor example creating a program showing an undefined number of pictures, see figure 3.2.Instead of creating one frame for each picture it would be much easier if the program wouldallow one frame to load all the pictures and show them one by one when pressing the rightor left arrow.

The evaluation with only one evaluator, the author, still gave a whole list of shortcom-ings indicating it was no waste of time. And as Jakob Nielsen would say, ”Bad user testingbeats no user testing” [23].

36 Chapter 5. Discussion and conclusions

Chapter 6

Acknowledgements

I want to thank my family and friends, they gave me support and encouragement throughoutthis project. I also want to thank my supervisor at Neava, Staffan Johansson for guiding methrough the degree project and for all the rewarding discussions. My supervisor at UmeaUniversity, Lena Palmquist, thanks for the encouragement and helpful tips in regards to themaster thesis. And I also want to thank the other master thesis students and the employeesat Neava for inspiration and contributing with an enjoyable workplace.

37

38 Chapter 6. Acknowledgements

References

[1] Apple Inc. Apple Announces Over 100,000 Apps Now Available on the App Store, 2009.http://www.apple.com/pr/library/2009/11/04appstore.html (visited 2009-11-10).

[2] Unknown Author. Satin. http://www.satinproject.se/ (visited 2010-05-10).

[3] Unknown Author. Wikipedia. http://sv.wikipedia.org/wiki/Gestalt (visited 2010-01-11), 2010.

[4] Unknown Author. Wikipedia. http://en.wikipedia.org/wiki/Wikipedia (visited 2010-06-11), 2010.

[5] C. George Boeree. Gestalt psychology. http://webspace.ship.edu/cgboer/gestalt.html(visited 2010-06-10), 2000.

[6] D Cameron. The rocket in your pocket: How mobile phones became the media bystealth. In Proceedings of Second Joint Journalism Education (JEA)/Journalism Ed-ucation Association of New Zealand (JEANZ) conference, Auckland, New Zealand,December 4-7 2006. http://artsweb.aut.ac.nz/journalism conference/docs/paper-DavidCameron.doc (visited 2009-11-30).

[7] Princeton University definition. Law of closure.”http://wordnetweb.princeton.edu/perl/webwn?s=Law+of+Closure&sub=Search+WordNet&o2=&o0=1&o7=&o5=&o1=1&o6=&o4=&o3=&h=0” (visited 2010-01-11),2010.

[8] Princeton University definition. Law of continuation.”http://wordnetweb.princeton.edu/perl/webwn?s=Law+of+Continuation&sub=Search+WordNet&o2=&o0=1&o7=&o5=&o1=1&o6=&o4=&o3=&h=10” (visited 2010-01-11), 2010.

[9] Princeton University definition. Law of proximity.”http://wordnetweb.princeton.edu/perl/webwn?s=Law+of+Proximity&sub=Search+WordNet&o2=&o0=1&o7=&o5=&o1=1&o6=&o4=&o3=&h=0” (visited 2010-01-11),2010.

[10] Princeton University definition. Law of similarity.”http://wordnetweb.princeton.edu/perl/webwn?s=Law+of+Similarity&sub=Search+WordNet&o2=&o0=1&o7=&o5=&o1=1&o6=&o4=&o3=&h=0” (visited 2010-01-11),2010.

[11] Lisa Graham. Gestalt theory in interactive media design. Humanities and SocialSciences, 2:1, 2008. http://www.scientificjournals.org/journals2008/articles/1288.pdf(visited 2010-01-11).

39

40 REFERENCES

[12] Chang D. Dooley L. and Tuovinen J.E. Gestalt theory in visual screen design: A newlook at an old subject. In Proceedings of the Seventh world conference on Computersin education: Australian topics, volume 26 of ACM International Conference Proceed-ing Series, pages p.5–12, Copenhagen, Denmark, July 29-August 03, 2001. AustralianComputer Society, Inc. http://portal.acm.org/citation.cfm?id=820062 (visited 2009-11-10).

[13] David A. Lauer. Design Basics. Holt, Reinhart and Winston, New York, 1979.

[14] Kevin H Liu. A taxonomy and business analysis for mobile web ap-plications. Master’s thesis, Massachusetts Institute of Technology, 2009.http://hdl.handle.net/1721.1/47870 (visited 2009-11-30).

[15] Andreas Mettavainio. A program that creates programs, an evaluation of graphicallycreate and manage a mobile phones system architecture. Unknown Journal, 2010.http://www8.cs.umu.se/ dit05amo/studentConference/structuren.pdf (visited 2010-05-10).

[16] Neava. Neava. http://www.neava.se/ (visited 2010-05-10), 2010.

[17] Jakob Nielsen, editor. Guerrilla HCI: Using Discount Usability Engineering to Pene-trate the Intimidation Barrier, 1994. http://www.useit.com/papers/guerrilla hci.html(visited 2010-03-19).

[18] Jakob Nielsen, editor. How to Conduct a Heuristic Evaluation, 1994.http://www.useit.com/papers/heuristic/heuristic evaluation.html (visited 2010-03-19).

[19] Jakob Nielsen, editor. Ten Usability Heuristics, 1994.http://www.useit.com/papers/heuristic/heuristic list.html (visited 2010-03-19).

[20] Jakob Nielsen, editor. Why You Only Need to Test with 5 Users, 2000.http://www.useit.com/alertbox/20000319.html (visited 2010-03-25).

[21] Jakob Nielsen, editor. Heuristic Evaluation, 2005.http://www.useit.com/papers/heuristic/ (visited 2010-03-19).

[22] Jakob Nielsen, editor. Quantitative Studies: How Many Users to Test?, 2006.http://www.useit.com/alertbox/quantitative testing.html (visited 2010-03-19).

[23] Jakob Nielsen, editor. Discount Usability: 20 Years, 2009.http://www.useit.com/alertbox/discount-usability.html (visited 2010-03-25).

[24] University of Illinois at Chicago. Face or vase.http://www.uic.edu/com/eye/LearningAboutVision/EyeSite/OpticalIllustions/FaceVase.shtml(visited 2010-01-11), 2010.

A program that creates programs, how to graphically create ... · For example: a window for input,...

Documents

Transcript of A program that creates programs, how to graphically create ... · For example: a window for input,...