“… how you build a picture, what a picture consists of, how shapes are relates to each other, how spaces are filled, how the whole thing must have a kind of unity.”

Chapter one covers the image frame and how the rectangular area influences a photography. Every time you take a picture, you make a decision whether you should use landscape or portrait format – the first basic composition attribute. You decide which elements to place in this area, where to align them or if you should show a close-up or show some surroundings. Virtual lines like the horizon divide the frame and enforce the viewer’s first responses.

The general design basics are taught in the second chapter. Contrast, balance, patterns, perspective and dynamic tension are just a few to mention here. Each of this topics is explained in detail with several images that show the effects they have and how they are used best.

Graphic and photographic elements follow in chapter three. Like in classical painting and illustration, an image is created by an alignment of points, lines and shapes. They help to compose and order an image and make the eye read what it sees. But a photo (as a result of the technical photographic process) adds several visual qualities, as Freeman names it. Light, exposure time and shutter speed can also be used as creative element and be seen as “part of the syntax of photography”.

Chapter four is about composing with light and color – the basic elements of photography. The effects, color and its combinations have on the atmosphere of an image or of course black and white are described. Contrasts and colors emphasize the graphic elements described in the preceding chapters. So the thoughtful reception and usage are the subtle foundations of a brilliant composition.

The intend a photographer wants to express with his work is the topic of chapter five. Reactive or planned, documentary or expressive, simple or complex, clear or ambiguous. Freeman outlines the basic attempts someone has in his mind when identifying a scenery worth capturing. For him, the key is to “remain aware of what you are setting out to do”. It’s about “overcoming the mindless ease of taking a picture”.

The last chapter of this fabulous, inspiring book is about the process of designing a picture. Freeman examines the question of how to work with the things he explained. “Hunting for a scene” to find situations for a meaningful image. The act of anticipation or reaction to the surroundings and context. And even post-production as an act of finishing a digital photography.

Michael Freeman, The Photographer’s Eye – Composition and Design for Better Digital Photos, The Ilex Press Limited, 2007, ISBN 1905814046

Component test

A component test generally tests each software module against its specification. This happens isolated form other modules to prevent external influences. It should not be mixed up with debugging as it’s not about eliminating bugs but about a structured way of identifying errors.

Component tests follow several goals:

• Test for functionality: Ensures, that the module fulfills the specifications functional requirements. A modules functionality is defined by its input and output parameters.
• Test for robustness: So called negative tests, which care about an appropriate exception handling. Therefore, the component is triggered with special cases and irregular input parameters.
• Test for efficiency: Efficiency of a component is defined by its use of ressources like memory or computing time.
• Test for maintainability: Maintainability includes those qualitites which influence how easy the component can be extended. Code structure, modularity, comments or documentation are the criteria.

Component tests are usually performed as whitebox tests on code level. The tester (or more common the developer) can simulate the flow of the program or the used parameters by manipulating the code itself. Modern component test follow the test first principle which means that all tests are considered before implementation starts. In this iterative process, the code is improved as long as all tests pass successfully.

Integration test

An integration test builds up on previous component tests of each single module. Groups of those components are assembled or integrated to a larger element or system. Tests in this step consider the interaction of the single parts with each other. So the goal is in finding error within the interfaces or the interaction with other components or external systems.

The main goal of the test is identifying faulty interface specifications or error in data exchange. The following error conditions are typical:

• Interface error: A sending component transmits none or false data so the receiving component can not work properly.
• Functional error: Communication works, but the involved components interpret the data different.
• Performance error: Data is transmitted correctly, but at a wrong moment or to slowly.

The chosen integration strategy is critical. Based on on the project plan and the system architecture, not all components are finished at the same time. The following strategies can be a help for planing:

• Top-down integration: The test starts which a component which is called once and calls several other components. The minor modules can be replaced by stubs which are replaced step by step by their real ones as they are finished.
• Bottom-up integration: The test starts with those components that do not call any further ones. The complete system is integrated step by step by high level modules.
• Ad-hoc integration: The components are integrated and tested as they ared finshed with development and component tests.
• Backbone integration: A program and process skeletton is set up which is filled stap by step with finished components.

What should be avoided is a so called big bang. This means that testing is not done before all components are finished and integration is tested all at once. With this situation it’s complex and time-consuming identifying the faulty components and get the whole system running at all.

The next part of the series will cover system and acceptance tests.

Testing shows presence of errors

In general, testing proves the presence of errors. Sufficient testing reduces the likelihood of existing, not discovered error conditions within the test object. It does not verify that no more bugs exist, even if no more errors can be found. Testing is not a prove that the system is free of errors.

Exhaustive testing is not possible

An exhaustive test which considers all possible input parameters, their combinations and different pre-conditions can not be accomplished (except for trivial test objects). Test are always spot tests. Therefore, the effort must be managed by risk, priorities and thoughtful selection.

Test early and regularly

Testing activities should begin as early as possible within the software life cycle. They should be repeated regularly and have its’ own agenda. Early testing helps detecting errors at an early stage of the development process which simplifies error correction (and reduces the costs for this work).

Accumulation of errors

There is no equal distribution of errors within one test object. The place where one error occurs, it’s likely to find some more. The testing process must be flexible and respond to this behavior.

Fading effectiveness

The effectiveness of tests fades over time. If test-cases are only repeated, they do not expose new errors. Errors, remaining within untested functions may not be discovered. In order to prevent this effect, test-cases must be altered and reworked time by time.

Testing depends on context

No two systems are the same and therefore can not be tested the same way. Testing intensity, the definition of end criteria etc. must be defined individually for each system depending on its testing context. E-commerce websites require a different approach than online-banking applications.

False conclusion: no errors equals usable system

Error detection and error fixing does not guarantee a usable system matching the users expectations. Early integration of users and rapid prototyping prevents unhappy clients and discussions.

Connectivity

Apps are always online as the device is constantly logged in to the mobile network. This allows user specific information or notifications being pushed to the App as they are available. In combination with the ubiquity of mobile applications, this is the most important characteristic. A service, that must be called actively to get a reaction is useless in a mobile environment. And with the growing number of Apps on each smartphone, this push-functionality becomes critical to keep an App in the users mind.

Convenience

An emotional design and a simple (one-handed) handling guarantees a high acceptance. A good App can do its job in different contexts and fast varying situations (changing environmental light and noise, unsteady movement of the device, etc.). So the information architecture and the overall usability must be planed with care to create a fitting and joyful interaction flow. Of course good content also counts to convenience. Analysing the users’ needs and creating a useful idea out of it is still essential.

Localization

Localization and the possibility to offer location-based information is a key feature that makes mobility vivid and practical. It separates the wheat from the chaff as it embeds the App to the users’ context. Sure, this feature might not make sense for every App but localization must not always be thought of as the big thing. Just think of automatically associate the location with a note or photo or by just limiting possible options or by sorting places. It can be useful in little, just creating a good experience for the user.

Reachability

Reachability covers a more social attribut given by the nature of mobile applications itself. A good App can really be used – and more important makes sense – anywhere at any time. The core of mobile devices is to be used anywhere at anytime. The same is true for Apps where reachability has become availability. Not in sense of usage, but in sense of updated information and perpetual usefulness. To much academic? Think of actual content round the clock, time-aware options or (again) context sensitivity.

Security

Security has several facets. The data transferred over the network must be encrypted through the carrier network. As some Apps sync data with online, web-based applications, the storage of this data on the server must also be secured. Another aspect concerns the data on the device itself. I don’t want anybody playing arround with my mobile phone getting access to my bank account data. Mobility is delicate, an so is the date aggregated and generated in this context.

Personalization

Creating personalized content based on individual usage or context is another characteristic. It builds on all previous characteristics as it is a kind of melting down of all of them. I want my App fitting my needs and I want my App behaving like I want it to do. This need covers not only personalized content but also control over data stored, shared or used for further actions. The option of turning localization on or off is true personalization. An individual background or personal categories are convenience.

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