General Resources

The Google Analytics Developer Docs provide comprehensive information about Google Analytics for both, beginners and experts while news, useful hints, tips and tricks about the tool are provided on the coresponding blog. The Analytics Channel on YouTube offers a bunch of clips, including the well known Web Analytics TV casts with Avinash Kaushik and Nick Mihailovski – a must see for web analytics experts (and those to become).

Event Tracking

Event Tracking is a method available that can be used to record user interaction with website elements, such as a Flash-driven menu system, outbound or download links. This is accomplished by attaching the _trackEvent() method call to the particular UI element that needs to be tracked (e.g. within the onclick function of an anchor element). When used this way, all user activity on such elements is calculated and displayed as Events in the Analytics reporting interface. Additionally, pageview calculations are unaffected by user activity tracked using the Event Tracking method. The design model for Event Tracking is highly flexible, and it an be extended well beyond the common model of user-triggered events. Events can be classified by category, action, event and value which requires a clean analysis strategy and planing about how the tracking should be integrated and how the metrics should be calculated later on.

Site Search

With Site Search, you can see how people search your site once they are already on it. There is no additional tracking code necessary. The feature can be activated within the Google Analytics interface by just setting the search query parameter (a simple request parameter reflecting the users search term within the search context). The report not only shows the site users initial searches, but how they attempted to refine searches when they didn’t find what they were looking for. You can see which pages they searched from and where they ended up and how site search correlates with conversion an other activities.

Ecommerce Tracking

If you run a ecommerce site, the Ecommerce Tracking feature will allow you to track and analyse ecommerce activity. Basically, it is based on the same principal as standard pageview tracking. JavaScript code sends some data to a Google Analytics server by requesting an invisible gif file. The big difference is that ecommerce data is sent rather than pageview data. The data transmitted is stored in a transaction object, containing all the related information about a single transaction, such as the order ID, shipping charges, and billing address. This transaction object itself contains several orderline items and the details about a particular item, such as SKU, price, category, and quantity. As with the Site Search feature, Ecommerce Tracking must be enabled in the profile’s settings.

This feature can not only be used for tracking real commerce activities, but also for tracking conversions (as Google Analytics still lacks a pure conversion tracking). For example, the report features “Days to Purchase”, “Visits to Purchase” or “Product Performance” can simply be mapped to activities like ordering a newsletter, subscribe to a feed or getting in contact. Knowing how many visits to a site it takes to convert a visitor in doing some action is useful and tracking those informations is very simple. Just use fixed values for your items and transactions so all activities get summed up. E.g. track an “product” item that is called “Newsletter” with a fixed price, category and quantity whenever a user submits a registration form.

Custom Variables

Custom variables are name-value pair tags that can be added to a sites tracking code in order to refine tracking. With custom variables, additional segments, others then the ones already provided by Google Analytics, can be applied for tracking and help to add more information to Google Anylatics. They can be used for content categorization, segmenting members from non-members, tracking campaigns a visitor sees prior to converting and many more. Custom Variables can be used in three different scopes:

• The visitor-level is active for the live of the visitor cookie and helps to distinguish categories of visitors across multiple sessions. E.g. you can track demographic information, customer type data (customer, subscriber etc.) or source information (where did the visitor come from).
• The session-level scope is active for a visitors session and allows to distinguish different visitor experiences across sessions. E.g. a custom variable can be scoped to the session level for user login status or for recording that the visitor viewed a special section of the site.
• The page-level scope is active for single pageviews, events or transaction calls. It is used to define a collection of page-level activities by users. E.g. on a blog website, this level can be used to track the category an article is assigned to (to get the most popular categories). This scope might collide with Event Tracking, so a good planing on how to use both features is required.

Custom Variables are tracked by using the _setCustomVar() method. It requires a slot-id, a name, a value and a scope definition (visitor, session, page).

Relevance

Links from pages that cover the same topic as the target page, or are closely related, are worth more than links from unrelated pages. The relevance is always determined in the context of the search query. See the article on Relevance and Importance of Search Results about how this aspect is judged by Google and others.

Authority

Taken relevance a step further is the aspect of authority. Each topic a user can search on has some authority sites that are specific to that topic (the most relevant sites). Authorities are sites that are linked to by most of the sites relevant to a particular content. Also involved is the concept of hubs, sites that link to most of the important sites which are relevant to that topic. So links from sites that search engines consider authoritative are evaluated very high.

Trust

Trust takes into account how likely the linking page is infiltrated by spammers. This trust measurement is determined on how many clicks away the site is from so called seed sites, sites that are manually picked and rated as trustworthy. The more clicks a site is away, the less trust it earns, the lower is its TrustRank. Generally, this factor is difficult to measure.

Anchor text

The anchor text the linking page uses is a powerful factor for search engines to determine the relevance of the target page. Anchor text helps the engines to understand what the link is about. So a keyword rich text adds much to the links value.

Independence

Links from independent, third-party sites are evaluated much higher than internal links from your own site. They are seen as independent editorial votes for your content. Search engines also consider so called link cluster building: sites, that heavily cross-link to each other are seen as one site and the links are treated as internal links (and therefore evaluated less).

Cumulation

Search engines do not count multiple links from a domain (or link cluster) cumulatively. So linking to a target site on every page does not have any additional effect. Ten links from ten different sites are evaluated higher than ten links from one site.

Diversity

Getting links from different page types, like blogs, social media sites, bookmarking sites, adds to the target page’s diversification. Engines are constantly upgrading the algorithms used for link evaluation. So if all links come from blog-like sites and the engines decide to reduce the value of blog links, your rankings will be influenced strongly. Another aspect of diversity is that gaining links from different types looks more balanced to the search engines and therefore more natural.

Temporal patterns

Temporal factors include when the target site gets new links, how long the links existed and how quickly they were added. Links that exist for quite a long time might become less valuable, depending on the trust and authority of the linking site. Interesting for search engines is the period within which new links appear and whether the site jumps from one link per week up to 10 per day. This might be a signal for the search engines to take a closer look and to decide wether the link building is correct.

Context

Search engines also examine the context where the link is placed. Do other, nearby placed links point to content related pages? Is the link placed in the body of the content or in a link section at the bottom of the page (prominence)? Is the content related to the targets page content? Does the nearby text seem to be related to the anchor text (proximity)? Does the overall site context fit or is the link only placed in a small fitting section?

Domain

Relevance and authority is not determined on per site basis. A section under example.com/seo might be evaluated authoritative on the topic of seo, but example.com/flex might not be for the flex topic. Every site and the pages it has are judged on topic-by-topic.

Relevance describes the factor to which the documents and their content match the user’s search term and intention. Importance on the other hand is a way to determine how the relevant pages rank.

To determine relevance and importance, search engines rely on sophisticated algorithms for information retrieval (IR): document analysis (including semantic connectivity) and link analysis.

Document analysis and semantic connectivity

In document analysis, the search engine searches for the relevant terms in important structural elements of the document like the title, the metadata, heading tags and of course the text body. As simple, textual analysis is not enough, the engines also look at semantic connectivity. This refers to phrases or words that are typically associated with each other like browser and internet. Out of this the engines build up their own dictionary and thesaurus to determine related terms and topics. Based on this databases they use algorithms based on fuzzy logic to connect terms and understand pages and sites more clearly. This is done by measuring how often and in what contexts some terms are used together.

For example, by analysing the data the engine captured by crawling billions of pages, it would recognize, that the term photography trip often include landscape, architecture and travel.

Link analysis

By using link analysis, search engines measure which pages or sites link to each other and if these sites are trustworthy, based on the authority of sites linking to them. Link analysis does not only count the number of links – links form highly authoritative sites count more than links of lesser authority.

Another aspect of link weighting is the so called link neighborhood. Basically your site is placed in a neighborhood about the topic of your content. The number and quality of links to your site form sites in your neighborhood says something about how important your site is to that topic. So links from nonrelevant sites do not weigh as much as those from relevant ones.

The anchor text which is used linking to your page also plays a relevant role as it has a strong impact on determine relevant keywords. So a keyword rich link text has more value than the often seen “click here” (but keep in mind: search engines also take a look at the target’s content and if it fits the anchor text).

To sum up: Search engines can use semantic analysis to identify relevant web pages that focus on a certain topic matching the user’s search query. Link analysis on the other hand helps to determine which pages have the most links from other sites focusing on the same topic. These sites are most likely to be more authoritative on the topic than others with less links and are therefore ranked higher.

Of course there are a lot more ranking factors that influence the ranking of pages for a search query – but content and link analysis form the general idea behind most of them to determine the relevance and importance of search results.

The Goal of the context analysis is to separate the system from its environment and highlight those parts which are relevant and affect the requirements. Therefore, assumptions about how the future system will be integrated in its reality must be made. In order to fully and accurately identify the requirements, it’s necessary to find all relations between the system and its future environment.

System and context border

For defining the system context, it’s necessary to border it form the system and the irrelevant part of reality. Through system and context borders, the system context is defined. It covers all aspects which are relevant for the requirements and can not be designed during the development of the system. Therefore, two processes are defined:

• Defining the system border: This process determines which aspects will be covered by the new system (the systems scope) and which aspects are part of the environment. All elements within the scope can be influenced and designed during development. Within the border, there might be a hardware and software based entity. Interfaces to external systems form the border and offer points for interaction.
• Defining the context border: This process determines the border of the context to the irrelevant reality by analysing which parts of the environment have a relationship with the new system. Entities within the context are typical sources for requirements. This might be stakeholders, external systems, existing processes, events and actions or legal definitions

Twilight area

Both bounderies mostly become precise not until the end of the requirements engineering process. Afore, some requirements are known only partial or not at all. This fuzziness results in a twilight zone that exists in different times throughout the engineering process. For example, at an early stage of the project, it might be unknown if a defined functionality must be implemented by the system or if it will be offered by an external system.

For the system border, this area might flow, considering aspects that are assigned to the context first and then move into the system itself. For the context border, this area flows if it’s not clear if certain environmental aspects influence the system or if they can be considered as irrelevant.

Documenting the context

Typically, the system context is documented by using use-case, data flow or class models. All three illustrate the different actors in the environment and their interaction with the system. For a complete documentation, different forms are used, highlighting changing perspecitves on the system and its environment.

Content and keywords

Offering top quality and useful content will influence a website more than any other optimization technique. Fresh and unique content will keep your visitors comming back an bring new ones to your site. It’s important to take a second and think about relevant keywords a user might search for and which could be associated with your content. These keywords should be used in the text – but spammming must be avoided.

Content must be organized and split up to several blocks, using headlines and paragraphs. This helps users find the content they are searching for faster. Well written and structured text that is easy to follow is more likely to be linked from other resources like blog posts or social media services – helping to build the site’s reputation.

Optimizing page elements

Webpages can also be optimized by turing one’s attention to single page elements. To name the most important:

• Headeline tags: Besides structuring a text with headlines has a high impact on its readability, it helps search engines to better “understand” the content and improve the keyword association. Headlines should be strucured hierachical to underline the importance of sections. and aid the user aand bots while navigating through the content.
• Images: Search engines can not see the content of images, so it is important to tell them about. What bots can read are the image url and the alt-attributes text, which should describe the image brief and descriptitve. Cryptical names do not carry any useful information.
• Page titles: The title-tag of a website should contain an accurate title, telling visitors about the page topic. They are also usually shown in the first line of the search result. and therefore must communicate and describe the content briefly. To enable users and search engines to distingush different pages, the title must also be unique within the site.
• Meta tag: A description-meta tage gives search engines a deeper summary what the content is about. Whereas the title offers only space for a few words, the meta tag may be a sentence or even a short paragraph. Like the page title, the description must be accurate and unique.
• Nofollow links: Be aware of using the rel="nofollow" attribute with links. This attribute tells search engines that your page’s reputation and popularity should not be passed to the page behind the link. It’s used to prevent the impact of spam comments on search results and page ranking.
• Anchor text: Anchor text should speak for them self, giving users a hint what they can expect on the selected page. It isused as a key indicator for identifying the topics of the pages they it is linking to.

URL structure and site navigation

Descriptive filenames and simple directory structures for webpages improve crawling the documents by search engines. If the URL contains relevant words, it provides users and search bots with more information about the content. This also has some positive impact for visitors as they get a hint where they are on the website. Each page should also have one unique URL linking to it. Duplicate content affects the ranking of a page negatively.

As the navigation is important to make users find the desired content quickly, it gives a search engine a hint about what role a page plays in the whole sites context. A naturally flowing hierarchy makes it easier for visitors to navigate from general to more specific content. Using text links for those navigation paths makes it easier for bots crawling and understanding the site.

HTML sitemaps for users and XML Sitemaps for search engines are an easy way informing visotors about possible content and ensures that bots and users discover the pages.

Overview

The package supports multiple log backends and formatting and filtering messages sent to the log. These functionality is devided into to the following objects:

• A Log (de.flamelab.log.Log) represents the basic object. An application can have as many Log objects as you like. Log objects can be sotred in the LogRegistry
• A Writer (de.flamelab.log.AbstractLogWriter) implements a concrete logging mechanism and is therfore responsible for saving the message to a storage. New Writers can be added by inheriting and implementing the abstract base class.
• A Filter (de.flamelab.log.ILogFilter) blocks data from being logged. A filter is applied to a Writer object and can be chained with other filters.
• A Formatter(de.flamelab.log.ILogFormatter) is used to format the log messages before they are written by a Writer. Each Writer has excatly one Formatter.
• A LogRegistry (de.flamelab.log.LogRegistry) can be used to gain convenient access to different Log instances among different classes.
• A LogEvent (de.flamelab.log.LogEvent) is used for encapsulating the necessary log information an is dispatched to all assigned Writers of a Log object.

Logging messages

To start logging, a Writer intance must be passed to a Log instance and the log() Method can be called on the Log. Additionally, the Log instance can be stored in the LogRegistry for further usage. Writer instances can be fetched through a static method of a LogFactory. A Log instance must at least have one Writer assigned with the addWriter() method to it to work properly. If multiple Writers are assigned, each Writer recieves the log data.

The log method accepts two arguments, the log message and a priority. The Log class defines the following priorites, based on the BSD syslog protocol, described in RFC-3164:

• EMERG – Emergency: system is unusable
• ALERT – Alert: action must be taken immediately
• CRIT – Critical: critical conditions
• ERR – Error: error conditions
• WARN – Warning: warning conditions
• NOTICE – Notice: normal but significant condition
• INFO – Informational: informational messages
• DEBUG – Debug: debug messages

By calling the log() method, a LogEvent instance is created an populated with all necessary data describing the log action. It is passed to all Writer objects and its creation is completely transparent.

Writers

A Writer is an object which responsibility is to record the log data to a defined storage. All Writer inherit and implement the abstract AbstractLogWriter class. Each Writer can be instantiated directly or it can be fetched through the LogFactory. The package already has the following Writer objects implemented:

• LogWriterFirebug: Writes the data to the Firebug Console.
• LogWriterAirFile: Uses the FileStream object to write log messages to a defined logfile on the clients’ filesystem.
• LogWriterAirSqlite: Uses Airs’ SQLite ability and stores messages in a automatically created, local database table.

All Writers are meant for logging certain application activities or errors during application runtime, not only while developing or debugging.

Formatters

A Formatter takes an LogEvent and formates its data in a predefined manner for storage. Some Writers are not line-oriented and cannot use a Formatter. The LogWriterAirSqlite for example takes the data from the event and inserts its values into the database directly.

Each Formatter must implement the ILogFormatter interface. The package includes a basic LogFormatterSimple that uses a user-defined pattern for arranging the data provided by the LogEvent in a message. It is also used for default formatting when no Formatter is specified. A Formatter is set on an individual Writer by using the setFormatter() method.

Filters

A Filter objects decides if a message should be stored or blocked from being written to the log. The addFilter() method is used to add a Filter to a Writer. They can be chained, as multiple Filters can be applied.
Each Filter mus implement the ILofFilter interface. The package comes with two predefined classes:

• LogFilterPriority: Only messages with a priority smaller or equal the given value are logged.
• LogFilterRegex: Uses a regular expression to decide whether a message should be blocked.

The package is part of the ASLib. Get the ASLib

Definition and tasks

To make a go of a development projekt, it is important to know what the concrete requirements are – and they must be documented in an adequate manner. But what is a requirement exactly?
It is a condition, which is required by an user (person or system) to solve a certain task or problem or to reach a goal.

On of the central aspects are the stakeholders. They are those persons who influence the requirements directly or inderictly and serve as a source for information. Ignoring a stakeholder often leads to wrong or incomplete definitions.

The first step in the process of requirements engineering is to identify the concerns of all stakeholders and possible other sources. There are several techniques to get the necessary informations through interviews, creativity sessions, out of analysing existing processes or by monitoring users and systems.

After gathering all requirements, they must be documented in a structured and adequate manner. A documentation or specification can contain natural language based prose or a more formal notation like UML diagrams.

Documented requirements must be validated and verified to play safe they fit all quality criteria. After all points are accepted by all stakeholders, the specification can be considered as complete and passed on to the system architects and developers.

The process of managing the requirements spins over the complete specification and development process. It enfolds all necessary measures for structuring and preparing the requirements.

The Requirements Engineer

The Requirements Engineer is at the center of events. He is in close contact to all stakeholders and has the possibility and responsibility to learn the ropes of the systems realm. One of his most important tasks is to recognize the needs of all involved parties and prepare and document them for the project. His job can be seen as a kind of interpreter for transforming the stakeholders requirements to a level that fits the architects and developers language.

To master this task, the engineer needs a lot more than just technical and methodical skills: Analytical thinking for getting into unknown topics fast. Empathy to recognize what the stakeholders really want. Communication skills, as gathering requirements and managing them is all about listening and asking the right questins at the right time. Solving conflicts within stakeholders and other involved parites. Beeing an advocat for the requirements and represent them to architects and the management board.

Classification of requirements

Basically, there are three different types of requirements:

1. Functional requirements define the functionality the system must provide to its users or external systems. Typically, they are subdivided into functional, beahvioral and structural requirments.
2. Quality requirements determine quality based criteria. They influence the shape of the system and usually have some impact on the functional points and reference performance, availability, scalability, portability, reliability and usability issues. They are often described as non-functional requirements.
3. Framework requirements can not be influenced by the projects participants. They apply to neighborhood systems or the process as a whole. Compared to functional and quality requirements, they will not be implemented but constrain the development and architectural decisions.

There are also more classifications based on attributes, priorisation or the level of detail.

Embedded engineering and management

Over the entire term of a development process, the requirements specification is the basis for different tasks:

• Planning: Milestones and work packages can be defined based on the specification.
• Architectural design: The detailed requirements (and the constraints) are used for designing the systems architecture.
• Implementation: Based on the design, the software is implemented
• Testing: Testcases are developed, following the requirements.
• Change management: If change requests appear, their impact on the system can be estimated while analysing the requirements.
• System usage, maintenance: Probelms that occur after releasing the system can be analysed according to the specification to determine whether it is an user, requriement or implementation error.
• Legal issues: The requirements specification ca be used as the main object of agreement between the client and the contractor.

The following Ant script shows an example configuration for a task running on Windows. There are a few things that have to be considered:

• ASDoc does not recognize the AIR libraries (the airframework.swc and airglobal.swc files) automatically. To make the tool find the classes they have to be added with the -library-path option.
• To run the task on Windows, the executable path must link to the asdoc.exe executable in the SDK directory.
• The documentation can be customized with the -package, -footer, -main-title and -window-title option

More information on Ant tasks and Eclipse.

The album brings back the band’s typical sound: pure energy and emotion combined with musical innovation. Pharell, Chad and Shay define themselves new with every single track. Variety and colorful ideas guaranteed. Whereas their first album In Search Of… was an imaginative, exploration of identities and their individual stories, Fly or Die reflected the sounds that influenced the group, Seeing Sounds grinds everything together and creates a tunes that blow up all borders and conventions.

The first track Time For Some Action is a bass-heavy low-rider that leads over to the infectious booty-bass single Everyone Nose an the choppy drum & bass like Spaz. Sooner Or Later has strong soul influences while Kill Joy is a pure riff-heavy rock song. And finally the fantastic Love Bomb which mixes rock and R’n'B styles with catchy Mariachi samples. Tracks of every flavour.

Sure, not everyone likes the same colors (wouldn’t it be a boring world out there?) and not everyone likes what N.E.R.D. creates but Seeing Sounds is really worth listening. Whether the album stands up to their previous ones or whether the new experiments are genious or mainstream, is another matter entirely. But bringing together all aspects of music (and business) and making people feel and see the fun behind building their sounds is something that lacks most artists out there.

Papervision scene

The Imagewall class is the base. It sets up the 3D papervision scene which contains all elements and it creates a camera object for controlling the view of the scene. It also creates the imagewall based on an array of imagenames.

To create the piclens typical flow of the wall, the camera is adjusted towards a dummy DisplayObject3D. To create the wall movement, only the dummy object and camera move with a certain offset to each other. The images keep their position.

Interaction controller

The movement of the camera and the object are controlled by an InteractionController instance which dispatches it’s own events according to hitting the arrow keys on the keyboard (or by a possible mouse movement). Encapsulating the interaction control into a seperate class totally seperates the user control from the Papervision logic as the gallery must only listen to events and dosn’t mind how they are created.

Image elements

Each image on the wall is represented by an Image object. It consits of a border or background area and a dynamically loaded image. In order to be rendered correctly by Papervision, it must be represented by a Plane object which contains a Sprite for the background, while the loaded image data is drawn as a BitmapMaterial.

As the image data is not available until the loading process is completed and the Plane is created upfront (for reserving the space an showing a possible loader element) the script resets the material when the onComplete-event for loading is fired. For the bttom row of the wall, the images also show a slight reflection – which has to be created before re-assigning the material as the reflection is part of the maretial.

As the script is only a small prototype, there are some open things that are not implemented yet:

• image selection
• smooth zoom in / out
• dynamic image loading
• mouse based control
• image preloader element

Watch the imagewall and download the sources: Flex imagewall