skin generator for trig.com / skingenerator för trig766095/fulltext01.pdf · 2014-11-26 · skin...

Skin Generator for trig.com / Skingenerator för

trig.com

A user friendly, browser based, CSS editor / Ett webbläsarbaserat verktyg förstilmallshantering

MARTIN KANERVA

[email protected]

2014-05-15

School of Computer Science and Communication.Computer Science and Engineering.

Master’s ThesisSubject: Computer Science

Supervisor: Stefan Arnborg, Inge FrickExaminer:

Commissioned By: Adocca Entertainment AB

TRITA xxx yyyy-nn

Abstract

This report revolves around social network communities, accessible overthe Internet using a browser. More specifically it discusses each mem-ber’s personal presentation page. Beyond just a name and fifty words oftext, how much more freedom is viable for this page? How can page pre-sentation be easily adjusted via a user interface? Are there any technicallimitations for implementation?

This work offered Adocca Entertainment a theoretical backgroundand an overview of the technical landscape in 2006. It discusses pos-sibilities and reflects on the intended audience and other requirements.It includes implementation of a prototype version of a browser basedCascading Style Sheets (CSS) Editor, called the “Skin Generator”. Thisinspired further development and allowed an informed decision to bemade.

Starting in the theoretical, by applying fields such as programmingparadigms, data modelling and user interface. Viewing the broader fieldand then discussing the implementation specifics of a prototype version.User interface is arguably one of the barriers to allowing users more free-dom when presenting themselves in online communities. The prototypeproposes a solution leveraging the Model View Controller paradigm intandem with the Direct Manipulation school and adaptation to intendedaudience.

Referat

Skingenerator för trig.com - Ett webbläsarbaserat

verktyg för stilmallshantering

Den här rapporten berör sociala nätverk och communities, tillgängligaöver Internet via en webbläsare. Mer specifikt behandlar den varje med-lems personliga presentationssida. Bortom ett namn och femtio ord, hurmånga fler frihetsgrader är möjliga här? Hur kan användaren hanterainställningar? Finns det några tekniska hinder vid en implementation?

Arbetet gav Adocca Entertainment en teoretisk bakgrund samt enöversikt över det tekniska landskapet år 2006. Rapporten diskuterarmöjligheter och reflekterar över målgrupp och kravbild för ett webbläs-arbaserat verktyg som låter användaren programmera Cascading StyleSheets (CSS), kallat “Skingenerator”. En prototypversion implemente-ras som en del av processen, vilket inspirerade vidare utveckling ochbidrog till att ett mer informerat beslut kunde tas i frågan.

Avtramp görs från det teoretiska, med områden som programme-ringsparadigm, datamodellering och användargränssnitt som centrala.Berör den större bilden för att sedan diskutera implementationsdetaljergällande prototypen. Att förbättra gränssnittet, som i relaterade lös-ningar oftast består av textinmatning, är viktigt. Genom detta minskarden friktion medlemmen står inför när den vill presentera sig annorlun-da i communitysammanhanget. Prototypen föreslår en lösning baserad iModel-View-Controller (MVC), ett paradigm som driver implementatio-nen. Läran om Direct Manipulation och målgruppsanpassning skänkerinspiration till användargränssnittet.

Contents

1 Introduction 11.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5 Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.6 Related Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Analysis, methods and solutions 92.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Data model for skin . . . . . . . . . . . . . . . . . . . . . . . 92.1.2 What can be altered and how? . . . . . . . . . . . . . . . . . 122.1.3 Configuration of skin element . . . . . . . . . . . . . . . . . . 122.1.4 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 Editing skins and their respective skin elements . . . . . . . . . . . . 142.2.1 Editable parts . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.2 UI considerations . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.3 Previewing Changes . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Delivery of the created skin to a visiting user . . . . . . . . . . . . . 16

3 Results 17

4 Conclusion 19

Bibliography 21

Chapter 1

Introduction

The trig.com site was an international social networking community available onthe Internet. In 2006, when the majority of the work contained in this report wasconducted, it had just started an invite-only phase and was gearing up for a publiclaunch. The work included the implementation of a prototype version of a browserbased Cascading Style Sheets (CSS) Editor, called the “Skin Generator”. The webpages on which this editor is to be utilised are personal presentations of people, mu-sicians and other creative artists in a social networking community. They consistof a static layout which all users share. By adding this customisation feature mem-bers are able to express their creative side and impress upon others their personaltouch. This in turn makes the community more dynamic and vibrating, hopefullyimproving the experience for all participants. During 2008, Adocca EntertainmentAB, the site operator, faced re-construction and as a result trig.com closed.

Taking a more general approach to the problem one sees that this is somethingthat is applicable to a wider range of websites, not just community based ones.Techniques and lessons detailed in this report could provide value when devisingeditors in such scenarios.

1.1 Definitions

AJAX - Asynchronous Javavscript and XMLA technique relying on callbacks executed asynchronously (in the background).Using Javascript, the programmer performs HTTP requests, typically relyingon the response to drive the User Interface (UI).

Back-endServer side code that is responsible for data storage/retrieval and generatingand serving all components of the webpage to clients.

CMS - Content Management SystemA system designed to allow editing and modifying of content as displayed ona web page.

1

CHAPTER 1. INTRODUCTION

CSS - Cascading Style SheetA text based format used to specify the presentation semantics (that is, thelook and formatting) of the HTML.

DOM - Document Object ModelA cross-platform and language-independent convention for representing andinteracting with objects in HTML.

Front-endThe presentational layer of the web page, as rendered by the browser. Consistsof HTML, CSS and Javascript.

HTTP Get / PostA generic, stateless protocol used over TCP/IP networks, outlined in theHypertext Transfer Protocol – HTTP/1.1 RFC 2616 by Fielding, et al. Getand Post are defined methods of transmitting data in this protocol. [6]

MVC - Model View ControllerA programming paradigm relying on the abstraction of functionality into threedifferent categories. Model, the central component, consists of applicationdata, business rules, logic and functions. Views presents information aboutmodels. The controller accepts input and converts it to commands for themodel or view. See figure 1.1.

ORM - Object Relational MappingA mapping between different type systems. In this report it refers to conver-sion of data from a database into program-native class instances. Lindgrenand Dahlström both describe the technique. [4; 8]

PNG - Portable Network GraphicsA raster graphics file format for lossless image compression. Supports 24-/32-bit RGB/A, the alpha channel controls image opacity. Outlined in ISO/IECstandard 15948:2004. [1]

Skin GeneratorThe system designed to change presentation of profile pages on trig.com. Anadditional layer, “skin”, applied on top of an existing template, allowing theuser the possibility to customise the presentation.

XmlHttpRequestAn API that provides some HTTP client functionality, described in the W3CWorking Draft, 2006 [3]

2

1.2. PROBLEM

1.2 Problem

The problem at hand is creating a web-based tool for customising style elements ofpersonal web pages, commonly refered to as profile pages. Marwick recognises theneed for this as well, writing in her 2006 paper:

“Overall, however, all social networking sites limit the user to an identitypresentation that is both highly pre-structured and singular. This isproblematic on three levels.” [10]

She then proceeds to describe the problems, the most prominent two being:“rigid profile structure encourages application driven behaviour” and “encouragespeople to define themselves through the entertainment products they consume”.Donath and Boyd identify the profile page as critical for any social network, writing

“The profile and network of links are the fundamental features of thesesites” [5]

This tool should require no knowledge of the underlying structure of the web-page. Traditionally this has been solved by allowing users the possibility to embed aself-made Cascading Style Sheet (CSS) into the page. However, since most visitorsof trig.com are not technically savvy, something that can appeal and be usable fora larger group must be envisioned. Arguably it is easier for the untrained to use aneditor which leverages a Graphical User Interface (GUI) rather than just allowinginput of raw text. Among many things it enables more and better feedback options,since each UI element can be tailored and coupled to the object it is affecting. Italso allows for browsing predefined values and illustrating the boundaries of theinput values in a more sensible way. MacLean et al. provides this analogy:

“The workers are living in the valley, tinkerers are living in the foothills,and the programmers are living in the mountains. In this metaphor,there are steep cliffs between the various hill-folk. Each of these studieshas demonstrated the difficulty for users in one class to perform tasksfrom another: the slope is not gentle; there are cliffs in the way.” [9]

In order for the skin generator to be successful, technology must bridge thecliffs between MacLeans villages. Making usage simple and as self-explanatory aspossible is important. However, as Weld et al. points out:

“High-quality adaptation requires the ability to learn an extremely ac-curate model of user behaviour.” [13]

For the trig.com skin generator the following list of key features was deemed themost important for an initial pilot.

1. Setting a custom background of an element.

3


2. Modifying font properties of the text contained in an element.

3. Customising groups of elements such as button and tab sets by selecting pre-made configurations from a library.

4. Limiting which elements are customisable.

5. Providing adequate feedback/preview of changes.

Making all of this work smoothly requires solutions for back-end, front-end andthroughout the implementation effort must be made as to make the GUI intuitive.

1.3 Purpose

This tool allows for easier customisation of web pages. A web application program-mer could develop a site and then implement the ideas in this report to allow for itsusers to customise the look and feel of profile pages etc. Most Content ManagementSystems (CMS) available offer some functionality for this, however they usually re-quire some underlying knowledge of HTML, CSS and/or Javascript. This approachcreates a big initial hurdle for the person doing the customisation, since the firststep must always be understanding the structure and layout of the page, its namingconventions and so on. In a typical setting this initial fact finding is then followedby drawing up a design and handing this design to a programmer who implementsit. It is no big leap to argue that such a big crew is typically not feasible to employin many self-publishing cases, such as the user’s presentational page on trig.com.Thus, one of the main purposes of this tool is to try to bridge this gap, empoweringnon-technical users so that they may express their creativity more freely.

The spectrum in which such a tool finds itself has on the one end full blown“What You See is What You Get” (WYSIWYG) editors like Microsoft Frontpageand Adobe Dreamweaver and on the other ready made, off the shelf installablethemes, used by blogging platforms such as Wordpress and Tumblr. This tool triesto strike a balance between these two extremes, and is intended to be somewhere inthe middle of the spectrum, employing both ready-made elements as well as allowingfor direct user control. In the report, a solution for implementing the features listedat the end of section 1.2 is outlined. It also includes guidelines and thoughts on keyfeatures of the GUI, so as to make the tool comprehensible for the intended users.

1.4 Background

People partaking in the activities of an online community all have different reasonsfor doing so. The community trig.com features elements of both social networkingonly sites, such as LinkedIn, and more content-oriented sites with less emphasison community, such as Flickr or Tumblr. In 2006, other companies in this nicheincluded MySpace.com, orkut.com, virb.com and to some extent Facebook, although

4

1.4. BACKGROUND

it had yet to claim the dominant position it commands in 2014. For communitiesthat allow user generated content, one key success factor is gathering a criticalmass of users producing content. Typically a small number of content producerscan satisfy a larger number of content consumers, so by gathering these users onecan obtain an advantageous position. In a community, many users are also whatToffler and McLuhan calls “Prosumers” [12; 11], implying that they both produceand consume content when using the service. Undoubtedly all users can benefitfrom the additional freedom a skin generator provides but it was envisioned mainlyas a mean to attract the producing users.

Styling a HTML webpage is usually done using a CSS file, in which you definedifferent style attributes such as text colour, font size and margins. These styles arethen attached to either groups of elements or individual elements contained in thepage. The definitions of groups and/or elements are called selectors, and a selectorplus a corresponding style is called a rule. These rules are then parsed and renderedon the client side when the web browser has downloaded all files.

In the skin generator, all pages start out with the same layout. This layout hasa multitude of selectors defined by a team comprised of designers and front endprogrammers. Some of the selectors are deemed user configurable, and for these theskin generator presents an appropriate graphical user interface. Examples of suchelements are main body text, button sets, and header background. Together, thegiven selectors and corresponding user-defined styles make up a list of CSS rules,which can then be packaged into a standalone CSS file. The controls need to betailored to better reflect the selected values, for example, when selecting colours,something similar to the colour picker in an advanced image editing software wouldbe much more intuitive than a textbox asking the user to input a RGB value inhexadecimal format. A full list of the custom controls is presented in section 3.4.

Another key area is preview functionality. The only out-of-the-box cross-browsersolution to loading a style sheet is to reload the complete page, an action thatwould be detrimental to the performance of the editor. In general, the cross browsercompatibility of Javascript is an issue in any web application. In 2006, cross-browserJavascript frameworks existed, but were not as advanced as in 2014, thus additionaltime was needed to fulfil this requirement. In order to better understand thisproblem, it is useful to study by which means Javascript and CSS modify a page.Javascript is a script language run on the client side. Each browser includes somelibrary to parse and execute the code contained in these files. Although standardsare ever emerging each browser has some specific implementation, often times withunique quirks. To get a better insight in how both Javascript and CSS function theDocument Object Model (DOM) must be studied.

The DOM is, as the M hints at, a model, more precisely a model of the currentHTML web-page. This model is a tree, having a node called document as root,representing the entire page. By traversing the tree outwards from this root allnodes and leaves passed represent the elements that make up the web page. Thereare paragraphs, headers, images, forms and so on. All elements have attributes,some are only applicable to that element type, such as the attribute action required

5


for the element form, but disallowed for all other elements. Two attributes thatare applicable to all elements are id and class. The value for id must be uniquethroughout a page, so it is effectively used to identify a single element. Class hasno requirement on uniqueness and is typically used to group elements together. Byusing id and class together, it is possible to programmatically specify all elementsof interest to the skin generator. The DOM is rendered upon loading the webpage,but it can be altered after loading by using Javascript.

To store things on the server side, or backend, some sort of application is re-quired. Implementation is typically done in higher level scripting languages. Adynamic type system can be a powerful tool when approaching the problem oftype conversion, one faced by the Object-relational mapping (ORM) for instance.There are many options here, popular ones include Java, Python, Ruby, PHP (opensource) and ASP (proprietary, owned by Microsoft), another option that has beenaround since the web’s early days is Perl. However, there is no need to feel limitedto any of these, as a matter of fact any programming language that can be tailoredto the HTTP protocol may be used. A typical web application uses a web server,responsible for receiving the request from the web browser, dispatching it to the ap-propriate application, waiting for the result and then sending it back to the browser.Apart from the code there is also some layer for storing data, such as a databaseengine or maybe just files in a file system. For almost every application this is theslowest layer, and it is orders of magnitude slower than even the slowest of scriptinglanguages. This gives the programmer a lot of options, since execution time is lessimportant. Sensible choices for web programming are high level scripting languagessuch as Python, Perl and Ruby, as they trade raw performance for implementationtime.

The application used serverside at trig.com is programmed mainly in Ruby, adynamically typed, object oriented, programming language. An open source webframework called Rails, is developed using Ruby. The Rails framework is builtaround the Model View Controller (MVC) paradigm. It provides an ORM for han-dling data in the model layer, and can connect to various databases. The controllerlayer consists of a routing package, mapping URL:s to specific functions. The viewlayer is supported by a templating language, used to render pages, be they HTML,Javascript, CSS, XML or anything else the programmer deems necessary. It imposesa certain structure and convention upon the programmer. See figure 1.1.

Since data must be stored somewhere, preferably on a central server (so thatmany users may enjoy the customisations), data would have to be sent to saidserver. In HTTP, this can be done using tradiotional Get and Post requests thatcome together with an inevitable page-refresh of the browser, or the more modernXmlHttp request. The technique of using XmlHttp requests is commonly referredto as Asynchronous Javascript and XML (AJAX). What it allows is to send a Get orPost request and then capture the response in a Javascript, modify the page usingDOM-techniques and thus save the browser from performing a full page reload. Itoffers an asynchronous update that can be used to enhance user experience.

In 2006 web standards work was not at the levels enjoyed in 2014, causing cross-

6

1.5. THEORY

MODEL

VIEW CONTROLLER

USES

MANIPULATES

SEES

UPDATES

USER

Figure 1.1. Model-View-Controller pattern. Image courtesy of the Wikimedia Com-mons [2]

browser issues when rendering pages. Since the user might not want or know how tochange browser, these limitations must be considered. Discovering such limitationshelped suggest alternatives regarding platform choices, implemented features andfuture strategies.

1.5 Theory

The work in this report relies on theory in the system design field. Key areasof interest are programming paradigms, data modelling, type conversion and userinterface. By applying these theories to the idea of a skin generator, a foundationfor practical implementation can be created. This theory allows us the opportunityto view the skin generator in a broader perspective.

As the user interface is of key importance to the skin generator, what previouswork has been done here? Frolish summarises the evidence from direct manipulationstudies.

“Advantages for direct manipulation have been demonstrated on wordprocessing tasks (Card, Moran & Newell 1983, Frese, Schulte-Gocking

7


& Altmann 1987, Jordan 1992), file manipulation tasks (Karat 1987,Morgan, Morris & Gibbs 1991, Margono & Shneiderman 1987). Thedirect manipulation interfaces here were display editors, Macintosh-styleoperating systems, desktop filing systems, and an interactive graphicspackage.” [7]

1.6 Related Solutions

Others have made commercial as well as open-source products solving similar prob-lems. Wordpress, Tumblr and other online self-publishing tools offer a way for anon-expert crowd to maintain an online presence. Microsoft offers Frontpage topeople interested in self-publishing. Frontpage relies on a WYSIWYG interface,commonly used by word processors.

One of the main competitors to trig.com during 2006 was the online communityMySpace. MySpace allowed custom CSS to be embedded on the page, howeverthere were limitations enforced. It had a text-based input and many third partiescreated tools to aid the users in customising their web page.

8

Chapter 2

Analysis, methods and solutions

2.1 Introduction

There are six main considerations for the skin:

• How is a complete skin represented and stored?

• What elements/groups can be skinned, and which alterations are allowed?

• What kind of values are needed to configure an element of a skin?

• UI considerations when editing skins and their respective skin elements

• Previewing and undoing changes to a skin

• Delivery of the created skin to a visiting user

The following sub sections presents the analysis, methods and solution to thesequestions. The method for arriving at the result is mainly fact-finding intertwinedwith the iterative development of a prototype version. This paradigm enables arapid cycle between idea and functional software. Using prototyping and iterationsis helpful when developing a UI, as a lot of intricate details typically emerge as soonas one tries to accomplish something using the software. Wireframes and similarmethods are typically used in larger scale projects of this kind. They serve as a userinterface blueprint and aid the work of a multi-disciplinary team. For this report,it was deemed too time consuming to employ, seeing as its main benefit is aligninga larger group whereas the group in this instance had only a few stakeholders.

2.1.1 Data model for skin

A layer of abstraction is needed between user settings and a CSS rule. For in-stance the background image could be represented via the background-image CSSrule but stored in the database as a file-pointer. Rather than storing the completeCSS-rule, in practice it is better to divide the information used to create the rule

9

CHAPTER 2. ANALYSIS, METHODS AND SOLUTIONS

into several fields. For instance by adding Boolean variables telling if the text isbold/underlined/italic and storing the font separate from the text size and back-ground colour. This is in any case necessary to implement when validating userinput, as bogus input must be prevented somehow. The model is illustrated infigure 2.1. The instances of the Skin model could possibly be presented in a libraryand shared among multiple users.

Taking an MVC approach to the problem, implementation is reduced to mappingmodel fields directly to available user input. This offers clear layers of abstractionwhere storage, user input handling, validation and presentation can be implemented.Combining the model illustration in figure 2.1 with the view and controller keyfeatures in figure 2.2 gives an overview of this.

Figure 2.1. Model layer for skin for skin generator.

Skin

• id, the primary key used to uniquely identify this object

10

2.1. INTRODUCTION

• user_id, owner, whose page the skin is applied to

• is_active, a boolean telling if the skin should be rendered for the users page.A user can have a maximum of one active skin at any given time. Inactiveskins may be previewed and edited in the skin editor.

SkinElement


• skin_id, reference to the Skin, each skin being made up from an arbitrarynumber of SkinElements

• premade_id, reference to Premade, if any.

• css_selector, a text string

• background_image, a text string with a pointer to the background image used

• text_is_bold, boolean

• text_is_italic, boolean

• text_is_underlined, boolean

• text_colour, RGBA-value

• text_font, string with name of the font used

• text_size, integer indicating text size

SkinImage


• user_id, uploader and owner of the image

• file, pointer to uploaded file.

Premade


• css_rule, a text string

11


2.1.2 What can be altered and how?

The first obvious step that needs consideration is the selection of elements andgroups for skinning. There is also the question of by which method these elementsare defined. As hinted earlier elements and groups of elements from web pagescan be represented using a CSS selector, offering a clear way to define skinnableelements. For each such selector there needs to be a list of allowed alterations, forinstance: colour, background image, font-size and font-family. For every base skinthere needs to be a defined list of (allowed skinnable elements, allowed alterations)tuples. Options for storing this data (ranging from simple to more complex) are:

1. Static variable in source code

2. Text file

3. Database

4. Parsed from a web page

The key issues are speed, simplicity and flexibility of the solution. Using thestatic variable is fast and simple, but not very flexible. To allow for new elements tobe skinned the web server would typically need to restarted. Text file storage helpsthis because a function to reload this file could be implemented, thereby avoiding arestart of the web server. Database storage makes managing the skinnable elementseasier, as using a database could let semi-skilled users update the skinnable elementsvia an administration page on the site. The main disadvantage of this approachis the increased complexity of the solution. It is also slower than both the textfile and the static variable since the database would have to be queried every timeinformation about the skinnable elements are requested. To alleviate long loadingtimes for file- or database storage solutions a cache layer could be implemented.

The fourth idea is to parse the page that is to be skinned, then store all thepossible ids and classes in some variable, and then let the user skin them. Whilethis is very flexible, since everything can be skinned, it is also the most problematicsolution of the four. By allowing everything to be skinned, and not allowing theweb developer to give any guidance to what the elements are, users are very likelyto be confused. Very often web pages also contain elements that are used strictly toovercome browser bugs and other formatting issues, and changing the backgroundcolour and text of these would probably not reflect on the web page at all. To sumit up the fourth path is typically error prone and potentially user unfriendly.

Considering that base skin seldom changes, it is acceptable to keep a list of allbase skins together with their skinnable elements in a static variable.

2.1.3 Configuration of skin element

Depending on what kind of alteration is allowed there is a need for a range ofdifferent values, from simple strings and numbers to user-uploaded images. An

12

2.1. INTRODUCTION

overview is available in figure 2.2. Strings and numbers are used for customisationsuch as alteration of text-size and element colours. To handle user-uploaded imagesthere needs to be a way to store binary data.

Figure 2.2. Views, corresponding to SkinElements, with various attributes (top).Controller and its resposibilities (bottom).

With the problem of skinning a single element solved, we can turn to the issueof customising a set of buttons and tabs. It is not always possible to skin somethingusing only one selector. Let this serve as an example: If you have a button setwhich uses an onmouseover effect, then you would need two selectors, one for thehover- and one for the default state. This type of skinning thus require us to createseveral CSS selectors and rules. Let us refer to this type of element as a “Premade”

13


element. When a user relies on a premade element, a chunk of CSS is the value. Ittakes away a bit of the flexibility, since they as the name tries to imply, this chunkhas to be premade. It offers limited alteration options in a clear way.

For the advanced users an option to enter self-made CSS could be supplied,but they are not the audience for the skin generator. When allowing arbitraryCSS one also has to keep security, particularly Cross-Site Request Forgery, in mind.For instance an attacker could introduce a CSS rule that loads an image hostedelsewhere and gain information regarding who is viewing content. A more commonscenario could be unmalicious syntactical errors. As such, ways of sanitizing theinput is required, ensuring it is both valid and unmalicious.

2.1.4 Storage

By relying on the models from the previous section together with an ORM, the datais stored in a database hosted on another server. In the stateless land of HTTP, oneway of maintaing state is by using a database. To control access and allow changesto be made, one or several application servers authenticate and serve data to clients.The application servers in turn communicates with the database to maintain state.To persist information regarding skins, database models Skin and SkinElement arerequired. In addition there is a need to store binary image data received from users,together with its related meta data. This corresponds to the model displayed infigure 2.1.

2.2 Editing skins and their respective skin elements

2.2.1 Editable parts

One obvious task is to decide which parts of the page should be editable as well astypes of alteration allowed for each part. Once specified it is a mapping of pageelements, represented by CSS selectors, to alteration options.

2.2.2 UI considerations

The skin generator is built to be modular, in that changing, adding, and removingof skinnable elements should be as easy as possible. With the considerations listedat the end of section 1.2 a set of allowed elements is produced, grouped by template,each with available configuration options for elements. For a new skin a blank editoris presented. When changing a current skin stored data is used to set the UI in thecorrect state upon load.

It is a web interface relying on HTML, CSS and Javascript. Each element canbe altered in one or several different ways:

• Font

• Colour

14

2.2. EDITING SKINS AND THEIR RESPECTIVE SKIN ELEMENTS

• Text decoration (bold, italic, underline, colour)

• Background (image or color)

• Changing “Premade” element(s) from gallery

Using lessons learned from Direct Manipulation the view as presented to theuser only show the parameters available for the selected element. Background letsthe user select background or upload a new file. “Premade” elements are presentedas a miniature gallery. Bold, italic and underline are displayed as checkboxes. Fontis a drop-down selection box. Colour has a widget of its own.

2.2.3 Previewing Changes

To see what effect a modification will have on the user’s page, a preview functionis needed. Main concerns for this function are:

• Should show the skin currently in use i.e. being edited

• Should have a revert function

• Should update in real time

Possible solutions for the first issue are: Loading the current skin in a newwindow, then reloading this window every time changes to the skin occur. It ispossible to make smaller snapshots of each element, for instance an element nextto the view showing how the change affects the page. Unfortunately both of thesesolutions have problems. Having a separate window forces the user to switch backand forth, and the page reload slows things down. Showing only a snapshot isprobably faster, but the user does not get a good sense of the overall look of thepage.

Addressing the refreshing issue first, it is possible to avoid a complete page re-fresh if CSS rules are dynamically added to the DOM. This is fine for most scenariossuch as text properties and colours, but complexity increases when allowing uploadof user material to use in background images etc. Each change is transmitted tothe server, which keeps track of the current skin being edited. The server sends aunique id back to the client, allowing the user to undo changes made to the skinduring the session. In this way the model, stored at the server, can keep track of thestate as presented in the view. By using AJAX, each change made to the page issent over to the server, which can then generate some response used to update theCSS dynamically via DOM manipulation. With this solution it is possible to resizeuser provided images on the server side, that are used in the skin and also in thepreview. The preview could be either displayed separately, with links and submitbuttons disabled to prevent bogus navigation. Another option would be taking amore WYSIWYG approach for a larger area of the screen, with small controllersfor input on an element basis. Exact UI implementation aside, the procedure is asfollows:

15


1. Send a request to the server containing the skinned object and alterationsapplied.

2. The server validates and stores this information in the database, writes back-ground images if necessary.

3. The server sends back the resulting CSS rule to the client along with a uniqueidentifier for the change.

4. The client loads the CSS into the preview area dynamically and stores changeid in a history list.

By sending the request in step one using AJAX techniques a complete pagerefresh can be avoided. Step two is a bit more interesting since the tool allows usersto select colours and select or upload images. The server validates the input andthen persists all accepted changes to the model in the datastore.

The data that the server sends back in step three are CSS rule(s) to update theview together with a unique id used to revert changes later on. By posting the id tothe delete skin element URL, the CSS rule to be deleted is sent back to the clientand can be removed from the preview. The skin element is also removed from thedatabase.

The image is handled on the back-end using a library called ImageMagick viaits Ruby wrapper RMagick. The ImageMagick library contains key features suchas format conversion, cropping and scaling (among many other things such as ro-tating, multi-image compositions, text overlays etc.). After conversion the image ispersisted and its URL can be sent to the client.

2.3 Delivery of the created skin to a visiting user

The complete set of CSS rules needed to skin the page can be generated by combin-ing the output from all individual skin elements with the base template css. Thisis calculated on-the-fly and stored in a cache layer for performance. When a useractivates/de-activates a skin the cached CSS rules are purged.

16

Chapter 3

Results

The work offered Adocca Entertainment a theoretical background and an overviewof the technical landscape in 2006. It discusses possibilities and reflects on theintended audience and other requirements for the skin generator. The prototypeversion inspired further development and eventually saw live usage. Adocca Enter-tainment was re-structured in 2008 and the social networking site known as trig.comclosed during the transition.

Using technologies at the forefront edge of web standars is not without its shareof cross-platform issues. As standards mature and browser adherence to standardsincreases, it is arguably easier to offer every user the same experience. By puttingtogether a multidisciplinary team different aspects of these problems can be moreeasily studied. It can offer valuable insight in how to overcome or circumveneproblems largely by reformulation or minor adaptation.

17

Chapter 4

Conclusion

The shelf life for web applications can sometimes be short. By researching the fieldand developing a prototype version a good foundation for further discussions can becreated. Sometimes simpler solutions can be advantageous, reducing cross-browserissues and decreasing implementation time.

By developing an understanding of the user and the problem at hand whendesigning a GUI, a more informed approach can be taken. With a Direct Manipu-lation Interface the user can with relative ease considerably alter enough elementsto establish a more personal profile, allowing them to become “Prosumers”. Inanother sense they are also bridging the gap to programming, instead of typing aCSS-rule they are dragging a slider or toggling a checkbox. Allowing easy, coherentand direct response to fewer elements seems to be preferable to offering access toeverything, since it lowered the learning curve among users as measured by usageand proliferation of the skin generator.

In 2014 much of the techniques to overcome cross-browser issues have been re-solved by better web standards adherence among browser providers. The explosionof mobile clients has given rise to an extensive list of rendering options when com-paring CSS 2.1 with CSS 3.0. Similarly for Javascript, many libraries/frameworksexist to combat cross browser issues in a pragmatic way. Mobile usage is ever in-creasing and looking at the emergence of HTML5 and responsive UIs it is likely tokeep growing. With it comes a broad userbase which encourages providers to offerwell though out user interfaces as a way to increase their user base.

19

Bibliography

[1] ISO/IEC 15948:2004. Portable Network Graphics (PNG), International Stan-dards Organisation. 2004.

[2] Wikimedia Commons. The model, view, and controller (mvc) pattern relativeto the user. http://en.wikipedia.org/wiki/File:MVC-Process.svg.

[3] The W3C Consortium. The XMLHttpRequest Object. http://www.w3.org/

TR/2006/WD-XMLHttpRequest-20060405/, 2006.

[4] Fredrik Dahlström. Building a modern server-side application framework usingopen standards and tools, section 2.7.1. Master’s thesis, Nada, The RoyalInstitute of Technology, Sweden, 2006.

[5] J. Donath and D. Boyd. Public displays of connection, BT Technology Journal,volume 22, issue 4. Kluwer Academic Publishers. 2004.

[6] R. Fielding, T. Berners-Lee, J. Gettys, J. Mogul, H. Frystyk, and P. LeachL. Masinter et al. Hypertext transfer protocol – HTTP/1.1. 1999.

[7] David Frohlich. Direct Manipulation and other lessons. In T. Landauer M. He-lander and P. Prabhu, editors, Handbook of Human-Computer Interaction. El-sevier Science Publishers B.V., North Holland, 1997.

[8] Tim Lindgren. Analysis of persistance frameworks in J2EE, section 2.5.3. Mas-ter’s thesis, CSC, The Royal Institute of Technology, Sweden, 2007.

[9] A. MacLean, K. Carter, L. Lövstrand, and T. Moran. User-tailorable systems:pressing the issues with buttons. In CHI ’90: Proceedings of the SIGCHI

conference on Human factors in computing systems, New York, USA, 1990.ACM Press.

[10] Alice Marwick. I’m a lot more than a Friendster profile: Identity, authenticity,and power in social networking services. In Association of Internet Researchers

6.0. Chicago, IL, USA, 2005.

[11] Marshall McLuhan and Barrington Nevitt. Take Today; the executive as

dropout. Harcourt Brace Jovanovich, 1972.

21

BIBLIOGRAPHY

[12] Alvin Toffler. The Third Wave. Bantam Books, New York, USA, 1980.

[13] Daniel S. Weld, Corin Anderson, Pedro Domingos, Oren Etzioni, and KrzysztofGajos Tessa Lau. Automatically personalizing user interfaces. In IJCAI’03

Proceedings of the 18th international joint conference on Artificial intelligence,San Francisco, CA, USA, 2003. Morgan Kaufmann Publishers Inc.

22

skin generator for trig.com / skingenerator för trig766095/fulltext01.pdf · 2014-11-26 · skin...

Documents