A new website is in progress and being built on a fresh database, without all of the baggage and refuse from old domains. With the launch of the new site, the feeds will work again and things should be better all around. I’m taking the opportunity to reorganize a bit, to purge the site of outdated information, tutorials that no longer pertain, etc. The more than three years of comments are also being eliminated, as the majority of them are now moot; the new site will instead emphasize support via the new Support Forum.

The transition to the new site will also include another change of address, though I expect it shall be the last. Stay tuned, and I will hopefully be launching the new site sooner rather than later. I won’t be having any weekends until the job is done.

Ria has graciously provided the full article in PDF format for download. For a better introduction to the article in Ria’s own words, and an explanation of the Royal Photographic Society, see the entry on Ria’s blog.

TTG Core Elements 3 Preview 1 is now available for download, comprising the new foundational page structure for upcoming projects. These are the features that will be common amongst new TTG3-designated web engines, the design elements that will tie your pages into your galleries, allowing consistency of design throughout your website. The foundation is being designed on HTML5, CSS3 and JQuery.

For more information and to download the preview, visit TTG Labs in the support forum.

Web-design is similar to digital photography in being also comprised of complex relationships, unintuitive numbers and obtuse terminology. But despite these categorical similarities, the two languages are worlds apart; one is French and the other Hindi. The web-designer’s vernacular is made up of terms like hypertext markup language, cascading stylesheet, accessibility, fluid grid, responsive design, element, selector, attribute, property, cookie, breadcrumb, graceful degradation, pseudo-class, etc. A language foreign to most photographers.

And yet, despite these differences, the two disciplines share some common ground. In our modern world, the Internet has become the photographers’ best means of exposing viewers to their photography. Inevitably, we enter the grey area where the worlds of photography and web-design collide, typically resulting in confusion. And while photographers need not become web-designers, it is important to understand Web as relates to images.

The Web is a wild place, and one of the grizzliest bears the photographer is likely to encounter is that of pixel density. Pixel Density is measured in pixels-per-inch, often abbreviated ppi, and is one of the most misunderstood aspects of digital imagery. In this article, pixel density will be explored, manipulated and explained. And in the end, you will come to realize the ultimate truth out pixel density and the web:

It doesn’t matter.

Pixel Density vs. Web Module: It’s a “Problem”

I regularly receive messages from Lightroom users bent out of shape after having realized that Lightroom’s Web module exports images at 240 ppi. The discovery typically manifests itself in distress over image piracy and illegitimate use, fears that visitors to the site will download the web-resolution image from the gallery, then utilize the image’s pristine 240 pixels-per-inch quality to create billboards visible from space while claiming the work as their own. The moon will crash into the earth, the seas will rise, and the world will end in flames.

My standard response to this distress runs something like, “It’s not important. Don’t worry about it.”

And this reply is generally not well received.

But notice above my intentional use of quotation marks around the word “Problem”. Because it’s really not a problem, except in the heads of photographers who have been misinformed, led astray of the truth and who, as a result, do not know what they are talking about.

Fact: Lightroom’s Web module exports JPG files at 240 pixels-per-inch.

Fact: It doesn’t matter.

Defining Pixel Density

Pixel density, a.k.a. pixels-per-inch, is an arbitrary value that defines for the printer the dimensions that should be considered 100% scale for an image. Pixel density dictates print dimensions only, not print quality. Quality, a.k.a. resolution, is instead a function of the total number of pixels comprising the image versus the size at which the image is printed.

The Dissemination of Misinformation

On the subject of pixel density, well-intentioned fools have long been spreading misinformation, the cumulative effect of which being the acceptance of falsehoods as truth by the masses. You can’t believe everything that you read, unless you read it at The Turning Gate. The Turning Gate never speaks falsely.

We will be addressing some of this misinformation below.

Pixels-per-inch and Dots-per-inch are Not Interchangeable Terms

Pixels-per-inch (ppi) and dots-per-inch (dpi) are often used as interchangeable terms. This is wrong; these terms are not interchangeable.

A 10 × 10-pixel image on a computer display usually requires many more than 10 × 10 printer dots to accurately reproduce, due to limitations of available ink colours in the printer.

As stated above, pixels-per-inch is an arbitrary value that indicates to the printer the dimensions at which an image should be printed at 100% scale.

Dots-per-inch refers to the number of dots sprayed into a square inch of space on the printed page, or to the printer’s capability to spray dots into an inch of space on paper. Printers may be rated by their dpi capability, with higher numbers indicating that the printer is capable of printing images of higher quality.

Experiment 1

Fact: 1-pixel does not equate to 1-dot, or to any other number of dots on the printed page.

We may illustrate this fact by performing a simple experiment.

First, open Photoshop. Set your colors to default, then swap them; do this by pressing ‘D’ then ‘X’ on your keyboard. Your foreground color should now be set to white, and your background to black. Press CMD-N on Mac or CTRL-N on Windows to create a new image. We are going to create an image 1-pixel wide by 1-pixel tall with a pixel density of 1 ppi, as shown in the image below.

Create an image in Photoshop with these values.

You should now have an image on your screen: one black pixel.

Print your image at its native 100% scale, without borders or frames. On the printed page, you should find a black square 1-inch in size.

As you can see, 1-pixel does not translate to 1-dot of ink; your printer sprayed many dots to create that 1-inch black square.

Let us now take the experiment further to show that pixels-per-inch is indeed an arbitrary guideline for printing.

Create another new image, this time 1-pixel wide by 1-pixel tall with a pixel density of 5 ppi.

You should now have a new image on your screen: one black pixel, seemingly identical to the previously created image.

As with the first image, print this new pixel at its native 100% scale. On the printed page, you should find a black square one-fifth the size of the previously printed image.

At this point, we have two images which are apparently identical on-screen, but which print to different sizes on paper. Clearly, the pixels-per-inch has an effect on print size. Pixels-per-inch does not have any effect on print quality, however, which we may demonstrate by making a third print.

Print again the 5 ppi image, this time scaled to 500%. You should find that the resulting print is identical to our first print, made from the 1 ppi image.

From this experiment, we may draw several conclusions:

• Images with equal pixel dimensions will appear identically on-screen, regardless of their pixel density.
• Regardless of the number of pixels in the image, the printer will create as many dots as necessary to scale the image to the specified print-size.
• Images of equal pixel size, but differing pixel density may be scaled to print at any size. When printed at equal sizes, the quality of the two prints will be identical.
• Pixels-per-inch and dots-per-inch have no correlative translation, and should therefore not be used as interchangeable terms.

With this new understanding of pixel density, let us dispel some misinformation from a popular and widely trusted resource.

According to Wikipedia, pixels-per-inch “can … describe the resolution, in pixels, of an image to be printed within a specified space. For instance, a 100×100-pixel image that is printed in a 1-inch square could be said to have 100 DPI. Used in this way, the measurement is only meaningful when printing an image. Good quality photographs usually require 300 dots per inch when printed.”

Notice the author’s use of DPI in attempting to explain pixel density. This is stupid.

It should correctly read, pixels-per-inch “can … describe the resolution, in pixels, of an image to be printed within a specified space. For instance, a 100×100-pixel image that is printed in a 1-inch square could be said to have 100 DPI PPI. Used in this way, the measurement is only meaningful when printing an image. Good quality photographs usually require 300 dots per inch more pixels when printed at larger sizes.”

The Myth of 72

Many photographers have fallen sway to the hearsay that an image being output for web should be saved at 72 pixels-per-inch. Another number sometimes kicked around in similar context is 96.

The belief that these numbers in any way relate to an image, however, is false. They never affect an image in any way.

So, where does this myth come from?

On paper, text font size in Points is dimensioned in inches. The definition of a Point is 1/72 of an inch, and so there are 72 points per real inch on paper.

Computer displays are dimensioned in pixels, without any correlation to physical forms of measurement such as inches. At some point, it was decided that computer users would require some correlation to printed text, however, and so the operating system simply dreams up and uses fake 72 and 96 dpi numbers to compute text size on the screen.

Programmers call this concept Logical Inches, which equates to pretend inches. The Windows operating system assumes one logical inch on screen to be 96 pixels, while the Macintosh operated system assumes one logical inch on screen to be 72 pixels. And so, if we simply pretend that pixels at these values will cover one inch on their respective screens (without asking the size of the screen), then we can use this to compute that a 12-point font should be shown to be 12-pixels tall on-screen using a Mac, and 16-pixels tall on a Windows display. And so we are happy, so long as we ask no questions.

And for a time, this flawed concept has sufficed for text. But as display resolutions continually increase over time, 12-pixel text-sizes begin to appear smaller and smaller to the human eye and will, at some point, become illegible. Bear in mind that these guidelines were imagined when standard display resolutions were 640×480, 800×600 and 1024×768. Today, screen resolutions of 1920×1200 are not uncommon.

When you cram more pixels into a the same space, those pixels must be smaller. Compare a 15-inch display at 1024×768 to a 15-inch display at 1920×1200, and this notion of correlating physical inches to computer display resolutions quickly falls apart. A 12-pixel font on the former is easy to read, while a 12-pixel font on the latter display borders on being illegible. On the latter display, the notion that 72 dpi = 1 inch of physical screen real estate doesn’t hold up.

So, that’s the story of text. How did the notion of 72 dpi become associated with images?

Let’s say you go to a friend’s party. At the party, you see a girl you’ve never seen before. Because she is at your friend’s party, you may logically assume she is your friend’s friend.

A similar thing happened with the notion of 72 dpi. The value being applied to text on screen was soon applied to everything else appearing on screen, including images. It’s a case of assumed association. But in this case, your friend has never met the girl at his party; somebody else brought her.

Pixel Density vs. Image Quality

Now that we have explained and dispelled the most common misconceptions about pixel density, let’s get back to Lightroom and information that qualifies as truth — the useful stuff.

Pixel density has no impact on image quality. Image quality depends not upon the number of pixels-per-inch, but the number of pixels that comprise the image.

We have previously established that computer displays are dimensioned in pixels. Therefore, the number of pixels wide by pixels tall will determine the size of the image on screen.

On paper, the image size at 100% scale is determined as pixels wide by pixels tall divided by pixels-per-inch. As demonstrated by our first experiment, however, an image may be scaled to a larger or smaller size and the pixels will simply be stretched to accommodate the specified scale. On paper, the image size is determined by the printer, while image quality is a factor of the total number of pixels in the image and the specified size of the printer. Spreading fewer pixels over more paper will result in an image of lesser quality.

To explore the impact (or lack of impact) of pixels-per-inch on our images, let us perform a second experiment.

Experiment 2

To conduct this experiment, download the two images below to your desktop.

550 x 367 pixels, 240 ppi

550 x 367 pixels, 72 ppi

Both images were exported via Lightroom’s Export module at 550 pixels wide by 367 pixels tall; the first image was exported at 240 ppi, and the second image at 72 ppi.

Examining the images, our first observation should be that the images appear to be of equal size and image quality on screen; the images above are both presented at full size.

By looking at the files downloaded to the desktop, we may also observe that both image files are 258KB in size. Despite having different ppi values, the two images are equal in file size. This is because the images consist of the same number of pixels.

Next, import the two image files into your Lightroom catalog. Go to the Print module. Print the two images at the same size. You may print them both to a single sheet of photo paper, or print them larger to separate sheets as you prefer. It’s a good idea to enable File Info to display the file name of each image on the print so that you know which image file corresponds to each print.

By examining the two prints, you should observe that two images of equal pixel dimensions and different pixel density, when printed at the same physical size on paper, will appear to be of equal print quality.

From this experiment, we may draw the following conclusions:

• The value of pixels-per-inch has no impact on image file size.
• The value of pixels-per-inch has no impact on the on-screen display size of the image.
• Both the size of the image on screen, and the quality of the image on paper are directly dependent upon the number of pixels comprising the image.

From this third conclusion, we may extrapolate:

• Prints of better quality may be produced by image files containing more pixels.
• Larger prints require larger image files (i.e. image files containing more pixels).

Experiment 3

This experiment is entirely optional and only worth performing if you require yet further demonstration of the impact of pixels-per-inch on physical prints of images.

Load the two image files above into Photoshop, then print each image at 100% scale. You should observe that:

• The 72 ppi image prints at roughly 7.6 x 5.0 inches.
• The 240 ppi image prints at roughly 2.3 x 1.5 inches.

Because the pixels-per-inch values of the images differ, the printer will interpret the image sizes differently relative to 100% scale.

The 240 ppi image will appear to be of higher quality, but this is only because the pixels are being printed smaller in order to accommodate the smaller physical size of the print. If you should print the 240 ppi image again, scaled to the same dimensions as the 72 ppi image at 100% scale, then you will observe that the actual quality of both images is identical.

Alternatively, you may print the 72 ppi image at a smaller scale. When scaled to the same dimensions as the 240 ppi image at 100% scale, you will observe that the actual quality of both images is identical.

From this experiment, we may draw the following conclusion:

• While the value of pixels-per-inch may affect the print size of an image at 100% scale, it has no impact upon the actual quality of the image, which is dictated by the number of pixels comprising the image and the area of the paper over which those pixels are being spread.
• Because printed scale may be changed according to the whim of the individual making the print, the value of pixels-per-inch becomes largely irrelevant.

The Eternal Quest to Protect Your Images

By now, you should understand that contrary to popular belief, pixels-per-inch has no impact upon the quality of your image, and therefore provides no measure of protection in preventing the download or unauthorized use of images from your website. So, what can you do?

First of all, forget about PPI. As I told you at the beginning of this dreadfully long article, and as you should now understand, IT DOESN’T MATTER. There is no reason to get bent up over pixel density.

So let’s drop the topic of pixel density and instead focus upon the things that do matter, the features that can actually help you to safeguard your images online.

Whether exporting images from the Export module or the Web module, Lightroom offers several options for protecting your images.
First and most relevant to this article is Image Size. We now know that image quality is directly dependent upon the number of pixels comprising your image. The larger your exported image, the better quality at which that image may be printed, with quality degradation being relative to the physical size of the printed image.

Because the pixel dimensions of the image control both the potential print quality of the image, as well as the display size of the image on screen, however, a balance must be struck between exporting the image at a size large enough for web viewing, and small enough not to be worth using as a print. As the photographer, it’s really up to you to find a balance that you find acceptable.

Naturally, we favor larger images for viewing on our website, but larger images put you at greater risk of unauthorized image use, as those images can be printed at larger sizes on paper while maintaining an acceptable print quality.

The next mechanism that may be used to provide some protection is the Image Quality slider, which controls the JPG compression of the output image files. With the quality scaled back, the images become muddier looking and the fine details less discernible. Again, as the photographer, it is up to you to decide where to draw the line between protecting yourself and presenting your image with an acceptable loss of visual quality relative to the pixel dimensions of the image. Experiment to find a value that works for you, and realize as well that different images may have varying thresholds for quality degradation.

Another method of protecting your images is to embed full metadata, including usage, copyright information and status, photographer contact, etc. This is not a perfect method of protection, as metadata may easily be stripped out of an image by anyone willing to make the effort. It certainly doesn’t hurt to embed full metadata, though; the only negative effect is a negligible increase in file size.

One of the best methods of protecting your images is to utilize Lightroom’s watermarking features. By visually overlaying your copyright information and web address on your images, you create a protective element that can only be removed by damaging the image either by cropping the watermark out or through digital manipulation. Most people won’t know how to do this, or won’t find the effort worthwhile. And depending upon the size and placement of your watermark, removal attempts may destroy the integrity of the image. However you approach the matter, watermarks are your best defense against online image theft.

Finally, your best defense is the simple fact that you own the original full size RAW image file, while an image thief would only have the web-resolution JPG — an image file that just wouldn’t hold up to most commercial uses of the image.

Coda

In this article, we have dispelled several of the myths and much of the misinformation surrounding the issue of pixel density. Having read this article and performed the included experiments, you should now have a better understanding of digital image quality and how it relates to your images on the web and on paper.

Should you have any further questions about pixel density or relating subjects, feel free to open discussion in the TTG Support Forum.

The most major change is support for the new FoxyCart 0.7.0. FoxyCart users will need to update their FoxyCart stores before using the gallery. This can be done from within your FoxyCart account’s Store Settings:

Set your store's to use version 0.7.0 in Store Settings, highlighted above.

A new demonstration gallery shows off the FoxyCart implementation here, featuring all new photographs taken along my drive from Dallas, TX to Los Angeles, CA during my recent move.

The changelog follows; bold-face items apply only to the Pro version.

v2.0.7 ( 2010-08-29 )

Updated FoxyCart support for the recently updated FoxyCart 0.7.0.

Updated Google Analytics support.

Fixed compatibility issues regarding shopping cart <select> boxes. Internet Explorer’s special needs are now met, and other browsers don’t have to look like crap.

Undid the 2.0.6 change to the password protection script, as it has caused problems for some users.

Additional debugging.

As is often the case, Google comes to the rescue — this time with Google Web Fonts. Google Web Fonts and the Google Font API allow web-designers to utilize a selection of new open-source typefaces on their web pages, and doing so is as simple as adding a snippet of code to your pages, and then specifying the font to be used in your styling instructions, per usual.

If you’re not a web-designer, I realize that last sentence might have frightened you. Bear with me a moment and all will be made clear and simple.

TTG web engines already include robust options for choosing and customizing font stacks for use in your web pages and image galleries. For those of you wanting still more options, however, Google Web Fonts integrates easily with the existing TTG feature set and offers a world of new typographic possibilities.

To begin, you will need to be using one of the more recent TTG web engines — such as TTG Pages or TTG Highslide Gallery — which contain controls for …

… Custom font stacks, such as this:

… Advanced Options, usually located in the Output Settings control pane and including the “Add script in <head>” option:

Having confirmed that, visit the Google Font Directory at the following address to check out your new typographic options:

http://code.google.com/webfonts

Step 1: Choose a Font

On visiting the Google Font Directoroy, you will be presented with a list of available fonts. These fonts are open-source and therefore free for you to use in your web pages. Peruse the list and, when you’ve found a font that you like, mouse over it to highlight your selection in blue. When you do so, you should see the words “Click to embed [font name]” appearing to the right of the list. In the screen capture below, I have highlighted the words in red:

Click these words to advance.

Step 2: Inspect your chosen font, Get the code!

And so I’ve chosen Droid Sans. The next page displays several examples of the font in use at various sizes and weights.

If you are satisfied with your selection, click the “Get the code” link highlighted in blue.

Step 3: Download and install the font(s)

This third step is optional, though recommended. You would probably like to be able to preview the font within Lightroom, and to do that you will need to have the font installed on your system. And so, on the page subsequent to clicking “Get the code”, scroll to the bottom of the page where you will find the font files available for download:

At this point, if you have Lightroom running, Quit Lightroom.

Download and install the new fonts; font installation will vary according to your operating system, but can usually be achieved simply by double-clicking the font file(s). Consult your operating system documentation should you need further explanation on how to install fonts.

Once you have completed installation of the fonts, you may launch Lightroom.

Step 4: Add the Google Web Font(s) to your image gallery

And now the sexy bit; it’s time to enable the new font in your web gallery. Because knowing is half the battle, understand that …

… you are able to view the font within Lightroom’s web preview because you have installed the font on your system (accomplished in Step 3, above).

… visitors to your gallery may not have the font installed, but will be able to view the font on your page because it will be fetched from the Google Font Directory.

These points establish that once you have completed Step 4, exported your gallery and published it to the web, everyone will be able to view the font on your web page. Now, let’s get down to business.

On the same page from which you downloaded the font(s) in Step 3, scroll back to the top and locate the section titled “Embed the font into your page”, pictured below.

There should be several check-boxes for the typeface’s various styles — Regular, Bold, Italic, etc. Not all typefaces offer the full range of styles; for example, Droid Sans does not include the italic style. You may as well go ahead and enable all of the available options. As you do so, the code snippet will update to reflect your choices. When ready, highlight the code snippet in its entirety, then copy (CMD-C on Mac, CTRL-C on Windows).

Return to Lightroom’s Web module, then Paste (CMD-V on Mac, CTRL-V on Windows) the code into the “Add script in <head>” option in your TTG web engine:

Next, you will need to instruct you gallery components to use the new font by adding it to your font stacks. Back on the Google Font Directory page, located the sample font stack:

This will show you how to call the font by name when adding it to your own font stack. Please note that if the font name is more than a single word, it will be necessary to wrap the name in single-quotes when adding it to the font stack. For example, the font Droid Sans must be writting 'Droid Sans', when added to your font stack, including single-quotes and followed by a comma, like this:

Keep in mind that individual gallery components have their own separate font stacks. For example, the menu fonts, gallery description title, subtitle and paragraph text, page footer and image captions all have separate font stacks. Therefore, you should be sure to add the new font to all font stacks where you would like it to appear. Otherwise, go about styling your image gallery as you normally would. When you export and upload the gallery to the web, the page will fetch the new font from the Google Font Directory, and it will be visible to all site visitors.

Coda

In conclusion, we have learned that web fonts may be included in TTG web engines from Google Web Fonts. Google Web Fonts gives web-designers new options in choosing typography for web pages, and ensures that all visitors will be able to see the chosen fonts regardless of whether or not that font is installed on the end user’s system.

To utilize Google Web Fonts within TTG web engines, users need only to insert the code snippet — provided by the Google Web Fonts page — into the “Add script to <head>” field within the Output Settings control pane of engines such as TTG Pages or TTG Highslide Gallery, and then to specify use of that font in the engine’s font stacks.

This update includes the latest version Highslide JS 4.1.9, featuring several improvements to Highslide functionality. Of note, version 4.1.9 provides a fix for a bug in AdBlock for Chrome and the new Safari 5 that prevented some users being able to launch large views of images. Both engines now also include a new slider for setting the zoom level of Google Maps, and all files have been explicitly forced to UTF-8 encoding, which should improve support for non-English characters and currency symbols in the gallery.

The Pro version has received a number of exclusive updates this time, including several stability and compatibility improvements made to the PHP scripting for both the PHP shopping cart and the password protection feature. Users may now select whether email messages received from the shopping cart will display in the usual format:

Item Name: 20100321-0035.NEF
Item ID: 20100321_0035
Size: 4×6\” print
Unit Price: $10
Quantity: 1
Total: $10

Or the new Compact format:

Item Name: 20100321-0035.NEF – Item ID: 20100321_0035 – Size: 4×6\” print – Unit Price: $10 – Quantity: 1 – Total: $10

Also, over long product selection boxes will no longer be truncated to fit within the thumbnail grid. Instead, they will overflow the grid boundaries, with overflowing content hidden from view. This may not be as pretty as before, but it is necessary to ensure full shopping cart compatibility for Internet Explorer users so that item prices and descriptions are not cut off from view. Complaints may be directed to Microsoft, for their browsers’ lack of proper support of CSS width on HTML <select> tags.

Finally, TTG Highslide Gallery Pro now includes modified layout and behavior when viewed on mobile devices such as the iPhone. This should improve gallery performance for visitors using mobile browsers, though gallery features such as shopping carts, info bars, client select features and other extras will not be available to mobile visitors. Users may choose to enable or disable this feature in the Output Settings control pane.

To download the update, subscribed users should use the download link provided at time of purchase.

The complete changelog follows, with bold-face items being exclusive to TTG Highslide Gallery Pro. If you’d like to discuss the engines or the update, please do so in the new forum.

v2.0.6 ( 2010-08-21 )

Updated Highslide JS to version 4.1.9.

Added Zoom Level slider for Google Maps.

All engine files now explicitly forced into UTF-8 encoding; galleries should behave better with non-English and other “unusual” characters, such as currency symbols and the like.

PHP Shopping Cart order emails can now be set either to “Normal” or “Compact” view. Compact view condenses order information to take up less space for printing.

Removed width constraint from product select boxes when using carts because Internet Explorer sucks.

Additional corrections and minor performance improvements to the PHP Cart.

Small fix to password protection script.

Added alternative gallery layout for viewing on mobile devices; some gallery features — shopping carts, info bars, captions, etc. — disabled in mobile mode.

And for anyone who might have been wondering, I’ve been settling in nicely in Los Angeles. My place is mostly put together now, the job at the new studio is going well and we’re picking up steam, and I’m enjoying my surroundings much more than I enjoyed Dallas. Thanks for your patience during the transition.

1) … is that I find myself repeating the same information over and over again in private channels, where the only person to benefit from that information is the singular person on the other end of the email.

2) … is that post comments are incredibly disorganized and nearly impossible for visitors to search for answers.

3) … is that the more time I spend on technical support, the less time I have to spend on product development.

For various reasons — lack of time, aversion to spam, etc. — I have not setup a forum prior. However, the winds of change have begun to tussle my hair and its simply time I gave in. The TTG Support Forum is now open for business at http://forum.theturninggate.net, and I encourage you all to use it. Questions asked and answered in the forum become public record, and should ultimately build into a searchable knowledge-base for TTG products, a resource from which new users can pluck the answers they seek. It also provides an opportunity for experienced TTG users to help out the newcomers, helping to alleviate the burden from my own shoulders so that I can focus more of my time on product development, from which we all benefit in the long run.

I will gradually be filling information into the forum, repeating tutorials from the blog, creating FAQs and sticky posts, and generally flooding the place with usefulness. In the meantime, if you have any suggests, requests, etc. for things you’d like to see happening in the forum or for forum categories you think should be added, there’s a forum for that! Post your thoughts into the TTG Website & Forum forum.

For the most part, I think the forum is pretty self-explanatory. Please post questions to relevant areas. For topics where there seems to be no relevant area, post to the General Discussion forum. And if you’d like to show off your TTG-made website to other users, there’s also a Showcase.

Go forth! Register! Discuss! And look forward to more site improvements and changes coming!