UPDATE: the presentation slides are now available.

It’s a little bit drafty, so any feedback or comments welcomed. I will republish as a HTML file soon.

Investigating privacy in depth has been one of the most interesting things I’ve done in a long time… though it has left me a little bit creeped out. Hopefully I’ll get around to writing a bit more about what I read, what I’ve learned, and what practical changes I’ve made.

When it comes to privacy, it is obviously insufficient to simply define an API in terms of an Interface Definition Language (IDL), such as  WebIDL and OMGIDL, within specifications. IDLs are limited in that they only allow one to express simple inputs, outputs, and data type constraints. Nevertheless, implementations exist based on specifications that only provide IDL definitions, which are agnostic to privacy.  To overcome these limitations, some implementers leverage  digital signatures as the means of enabling privacy-sensitive APIs in an application. For example, if application “X” is signed by company “Y” then allow application “X” to access API “Z”.

Java treats an application as unsigned, and reduces its privileges: meaning some APIs will not be available.

Such an approach to privacy is limited in that it hands control of privacy matters over to a third-party (the signer) and implicitly assumes that the end-users unquestionably, or via a End User License Agreement (EULA), trusts the signer as the authority to enable an API without necessarily informing an end-user as to what is going on “under the hood” – such a model is commonly seen in the Java application space.

Feature Requests

Others have extended the digital signature to enable API model by having software developers explicitly declare what functionality an application will use (lets call them “feature requests“). Upon installation, the end-user is presented with a dialog informing them of the capabilities the application will use, and if they wish to proceed. An example is Chrome’s browser extensions, seen on the right.

Chrome's browser extensions show the capabilities of a packaged application, but lacks information about consequences.

From a privacy perspective, this model is significantly better then simply enabling APIs based on digital signatures. However, this model is also problematic in that it often does not provide any meaningful information about, for instance, what “can access your browsing history” coupled with “access your data on all websites” means. It can be argued that this model unfairly puts the consequences of consent on the end-user, by entering them into an agreement with an application without recourse (i.e., “Yes website/application X, you can access my history data even though I don’t know what you will do with it.”).

I instead reverted back to WindowsXP (which we have now dubbed “the workhorse”). Out of frustration I also installed Ubuntu, hoping to free myself from Microsoft… alas, Linux still has a few years to go. The world is rosey again

A few interesting issues that emerged with relation to using Google analytics. The issue with this website is that it is used by both public users and users on an intranet. Intranet users at QUT may be authenticated to access resources on the intranet (such as the newswire website), but not resources on the internet. When an unauthenticated users tries to load a page with the following Google-provided code the browser attempts to load the script but eventually times out. This can take around to 60 odd seconds in Firefox (or something close to that, not sure exactly how long). The implication is that, to the user, the browser looks as if it is still loading content. And in the browser, it does not execute the
<script> tags. Below is the problematic code that Google provides:

<script src="http://www.google-analytics.com/urchin.js"  type="text/javascript">
</script>

<script type="text/javascript">
   _uacct = "UA-XXXXXX-1"; urchinTracker();
</script>

Looking at the code above, what essentially happens is:

1. urchin.js needs to load synchronously and block the second script tag from running
2. once loaded, the code inside the second script element must be run
3. if the code is run without the script first loading, then the urchinTracker() method will be undefined.

So, like I already stated, in the intranet scenario, the urchinTracker() method is never called because urchin.js is never loaded. To make the whole process a bit more “behind-the-scenes” I decided to recode the Google code so that it is run only once the document has executed it “onload” function. The following simply dynamically appends the DOM with a script element AFTER the document has loaded. If the script element can reach its src, then analytics info is sent to Google, otherwise, nothing happens:

window.onload = function(){
   var scriptLoadFunction = function(){
   _uacct = "UA-XXXXX-X";
   urchinTracker();
};
var e = loadScript("https://ssl.google-analytics.com/urchin.js", scriptLoadFunction);
}

function loadScript(url,aFunction){
var e = document.createElement("script");
if(e.addEventListener){
e.addEventListener("load",aFunction,true);
}else{ //try to force IE to work, but alas, it does not.
e.attachEvent("onload",aFunction);
}
e.type="text/javascript";
e.src = url;
document.getElementsByTagName("head")[0].appendChild(e);
return e;
}

The code works great in Firefox 2.0 but does not work in IE6 or IE7 (as IE does not support the addEventListener() function). If anyone has a work around to this problem, I’ll like to hear about it.

Here are some gems

Visual Design attempts to solve communication problems in a way that is at once functionally effective and aesthetically pleasing. (p1)

By communication, we mean the full process by which the behaviour of one goal-seeking entity comes to be affected by that of another through the reciprocal exchange of messages or signs over some mediating physical channel.p1

The goal of communcation-oriented design is to develop a message that can be accuratley transmitted and correctly interpreted, and which will produce the desired bhavioral outcome after it have been understood by its recipient.p2

We refer frequently to a visual language, by which we mean the visual characteristics (shape, size, position, orientation, color, texture, etc.) of a particular set of design elements (point, line, plane, volume, etc.) and the away they are related to one another (balance, thythm, structure, proportion, etc) in solving a particular problem. Any language system defines both a universe of possible signs and a set of rules for using them. Every visual language thus has a formal vocabulary containing the basic design elements from which higher-level representations are assembled, and a visual syntax describing how elements may be combined within that system.
p2

In the context of GUI toolkits, “…most toolkits impose unnecessary design restrictions as a side effect of their own implementation or internal structure.”p4

Basic principles of visual organisation developed through centuries of experience with print media have rarely been applied to the on-screen media, and communication has suffered as a result. p5

• Seamless experience
• Focused experience
• Connected experiece
• Aware experience

Seamless experienceWhen it comes to RIAs, the user experience should be seamless. Seamlessness applies to both the layout of information on an interface (static/spatial), and also the temporality of that experience (dynamic/temporal/spatial). Mullet cites the obvious example of page reloads and the quick flash of white that the user might see as a new page is loaded. Often this breaks the interface metaphor, particularly as it relates to tabbed interface elements. I agree that this is a significant problem, but have never felt it was a massive problem from a design perspective (the millions of happy Amazon users will bear witness to that!). Obviously, it is much better if the response of clicking on a tab is instantaneous, which I am sure we will see more frequently with XMLHttpRequest taking off.

Focus experience

The tools of the application should be task focused and not try to solve everything with one interface. “A focused experience has a purpose that is clearly defined at the outset and continuously reinforced” (p17).

Connected experience

The application will be both interoperable and able to cope with periodic disconnections from the network without disrupting the user’s productivity. Connectedness and disconnectedness should be as seamless as possible to the user experience, with the software either intelligently finding alternative way to access the network, or caching the user’s work locally until the network connection can be re-established.

Aware experience

Aware talks about an adaptive user interface. This can range from full adaptivenes , to simple little things like an auto complete function.

Jesse James Garrett defines user experience as “how the product behaves and is used in the real world” (p10). The above definition is interesting because it means that user experience, in a design context, follows form, and we all know that form follows function. That is, understanding how a user experiences an object takes place after a product has been put into a context where people are “realistically” using it. If the user experience takes the form of study to inform the design process, then it forms a feedback loop.

Anyway, Garrett (p22-23) breaks the elements of a user’s experience into 5 planes. These five elements are not concrete elements themselves, but more like logical development methodologies that come together to make a final form. The layers start from abstract ideas, such as the goals and user needs, and which slowly materialise into concrete representations as some sort of a user interface:

• The surface plane: presentational elements of a design
• The skeleton plane: the logical organisational structure of elements within the design
• The structure plane: overall logical structure of all the content of a web site and the logical content blocks which are presented to user as they interface with the site
• The scope plane: the scope of functionality on the site, and the logical tools that allow users access to that functionality
• The strategy plane: defines the aims and objectives of the site.

Design decisions made at any level ultimately affect the effectiveness of every other level.

Although lacking any historical data, Garrett (p28-29) describes the shift (and continual development) of the web as a publishing medium to an application platform: “Technology continued to advance on both fronts as all kinds of sites made the transition from static collections of information that changed infrequently to dynamic data-driven sites that were constantly evolving.”

Garrett continues by describing a web development community that was divided into two groups: those that approached the web from a software engineering approach, applying knowledge routed in traditional desktop software development. The other group approached the problem from a media distribution/electronic publishing perspective, relying on knowledge from electronic publishing, media distribution models, and information science. He describes this as a problematic duality of sorts, were half view the web as a software interface, and the other half as a hypertext system (p30).

Garrett continues (p31), stating that understanding the web as a software interface means looking at tasks. : “the steps involved in a process and how people think about completing them… we consider the site as a tool, or set of tools that the user employs to accomplish one of more tasks.” However, on the hypertext system side, the problem becomes one that relates to information: “what information the site offers and what it means to our users. Hypertext is about creating an information space that users can move through.”

Garret takes the development methodologies used by each group to refine the five layers listed above. This produces a hybrid development methodology where the needs of the needs of the business are juxtaposed with the needs of users. On strategy plane, we now find user needs and site objectives. For a banking website, for example, users need tools to be able to do their banking on-line, while the bank needs to cut costs of maintaining ATMs by introducing a web-based service.

On the scope layer, we now find functional specification and content requirements. The functional specification is the complete feature set to be used on a website, while content requirements includes what content is required for the site.

On the structure plane we now find information architecture and interaction design. Interaction design refers to “how the system behaves in response to the user” (p32). Information architecture refers to the logical groupings of content so that it makes sense to the user.

On the skeleton layer, we find information design covering both the software and hypertext side, but it is also complimented by interface design and navigational design. Information design refers to “the presentation of information in way that facilitates understanding” (p34). Interface design refers to “arranging interface elements to enable users to interact with the functionality of the system.” And, navigational design refers to “the set of screen elements that allow the user to move through the information architecture.”

Lastly, on the surface plane, Garrett puts visual design, what he defines as “the look of the finished product.” (all quotes are from p33-4)

To summarise, elements fall into either software interface (SI) or hypertext systems (HS) discourses, or on both sides (BS):

• Surface
• Visual design (BS)
• Skeleton
• Information design (BS)
• Interaction design (SI)
• Navigational design (HS)
• Structure
• Interaction design (SI)
• Information architecture (HS)
• Scope
• Functional specifications (SI)
• Content requirements (HS)
• Strategy
• User Needs (BS)
• Site Objectives (BS)

In practice, the expertise from each field becomes the goal of each layer. Each layer is a goal, not finished one at a time, but done relative to each other. The lower levels have a higher priority in the creating cycle, because they are the foundation and ultimately determine the form of the system.

The strategy plane

“the foundation of a successful user experience is a clearly articulated strategy” (p39).

Site objectives – what does the business want to get from the website (p41)

Business goals

Bran identity – as is relates to the political agenda in the communication process (p42)

Suceess metrics – what tools are used to measure the successful implementation of the site objectives and user user needs. “Concrete indicators how effectively the user experience is meeting the strategic goals.(p44)”

User needs – what do the users need from the website

User segmentation – used to identify different user groups (p47)

Demographics: age, gender, education level,

Psychographic “profiles descbbe the attidudes and perceptions that your users have about the world or agbout the subject matter of your site in aprticular.” (p47)