We here at Visual Lizard have some clients who have multiple sub-domains that they would like to track the Google Analytics statistics. The issue that we have come across in the past is that we might not want to set up a completely different account for those sub-domains. It is helpful to keep the overall statistics together for a full report on the domain as a whole.

For those of you who only make their way into Analytics on an infrequent basis looking for general visit and pageview numbers the statistics in the content breakdown area for a site can be a bit daunting to work your way through. Especially if you are looking for only a few specific statistics on a single sub-domain. The other day we were asked to find just that. I personally hadn't done that before, so I had to spend some time trying to find a way to display only the sub-domain statistics that I wanted. Below are the steps for doing just that.

1. Login to Google Analytics
2. Select the Site
3. Select Content Under Standard Reports
4. Open Site Content and Select All Pages
   
5. Set dates in the top right of the right column (statistics for specified period)
   
6. Below the graph set the Secondary dimension to Hostname
   
7. Click Advanced next to the search field
   
8. In the available field type the subdomain (subdomain.example.com)
   
9. Click Apply
   

Once you have the statistics you are after, you can bookmark the results like our client did. After that it will display the up to date information of that sub-domain and you won't have to go through hastle of setting up that search again.

Last week we were made aware of a display issue specifically with the rendering of an HTML email template in the Yahoo Mail browser. According to the Email Standards Project the Yahoo Mail Browser currently has a status of "Excellent". Initially we could not replicate the issue that had been brought to our attention and we could not give an explanation to why it was happening. Upon asking for further technical details about the person's computer we learned that it was only happening in his Safari browser.

It turns out that there are a couple of potential issues with Yahoo Mail in Safari. The first is the level of security. By default in newer versions of the browser these security settings are preset and shouldn't be an issue, however in older versions of the browser the user will likely have to change the security settings to be at least 32 bit encryption. The second and the more likely reason for our particular issue has to do with the Flash plugin.

The combination of several elements causing this issue are like a "perfect storm" of technology working together to make your life miserable. However the issue did cause enough problems to have a decent knowledge base of how to deal with the issue. According to the research I did while looking into the issue, the following steps should be followed to make sure that your Yahoo Mail will work in Safari.

1. Update to at least Safari 5.1.1 (Latest version as of this date is 6.0.2)
2. Update to at least Adobe Flash 11
3. Clearing the Flash Cache: Go to System Preferences, select Flash Player, then under Storage tab, click "Delete All..." button and then click "Delete Data" button.
4. Restart Safari.

The above steps were taken from an Apple discussion about people having issues with Yahoo Mail not displaying email in their Safari Browsers. While this may not be the answer to every issue with Yahoo Mail, it is likely that if there is an issue, it will have to do with the software's interpretation of the HTML, not the HTML itself.

The goal of the Email Standards Project is to have a consistent standard of display of the HTML used in emails regardless of the rendering engine being used to display the email. By doing this, the intended design to represent branding in e-Newsletters or e-Stationery by a company is represented accurately no matter what platform or email client is being used.

If you use Apple hardware and run OS X, you may encounter a mildly annoying Spotlight issue from time to time where it will not find a file, or an app.

To correct this issue, there are two things you can try. The first is described in this post (http://support.apple.com/kb/HT2409) by Apple. They tell you to use System Preferences > Spotlight > Privacy (tab). If you drag a folder or hard drive to the Privacy tab, then remove it from there, Spotlight will reindex that item. Sometimes this works.

The second option, which gives you a lot more control, is to fire up the trusty command line found in Applications > Utilities > Terminal and run a couple of commands. The command in question is:

sudo mdutil -E

The -E flag forces Spotlight to erase (hence E) the indicated volume information. If you want to be more specific, such as a folder with your writing in it, or your Applications, you can tailor mdutil as follows:

sudo mdutil -E /volume/path/to/folder

As with all things run in the terminal, when they work, there is no feedback. You just end up back at the command prompt wondering what's up.

For more information on the mdutil functions, you can hit up the Apple Developer documents on mdutil. 

Note: This is advice on the internet, use at your own risk.

There's usually no need to include the same content in multiple places on your website. After all, the whole point of HTML is to link from one place to another so it's always possible to have only one instance of the content in question. The only times when it's necessary to have two distinct URLs for the same content is when the surrounding navigation, headers, etc. need to change depending on the path the user took to get to it.

For example, when users are browsing through an online store by category it's a better experience when links to the category they were just browsing appear on the page showing information for a product. That allows them to quickly get back to look at other products. In cases like this, having only one URL for the product and keeping track of what the user was viewing in their session quickly gets out of hand. The user can, and often will, have more than one tab open viewing the same site and tracking which links were clicked from where can be complicated. From a programming perspective, it's far easier to have multiple URLs that show the same product, with the different URLs triggering the different navigation display.

But what effect will taking the easy route have on SEO? In the past, not much. For Google, however, this has changed somewhat since the Panda update in February of 2011. That update targeted "low quality" sites, specifically content farms that often have copy-pasted content matching a wide variety of search results and link farms set up to boost another site's SEO by linking back to it with specific keywords. Both of these types of farm site would frequently have largely identical content available at multiple URLs and multiple domains.

Prior to the Panda update, the main "negative" effect of having more than one URL for a given piece of content was that Google would list only one of them in their search results. After Panda, duplicate content pages lost a small amount of Page Rank. Google hasn't specified specifically how much or from what areas, but from what I've read the effect is largest when the duplicate content occurs across domains. It's also likely that keywords in the alternate URLs will not be used for ranking. The actual effect on non-malicious duplicate content, however, should be small. Sites with multiple domains should be redirecting the aliases to their main domain. They should also be using basically the same keywords in all of the URLs that reach a specific page.

However, if your site will have a significant amount of content that can be accessed from more than one URL, consider using rel=canonical. This is a method of indicating which URL you want search engines to use for the duplicated content. The main requirement is that one of the alternative URLs needs to be selected as the canonical one. All of the other URLs will then include a link tag in the page head pointing to the canonical url.

	<link rel="canonical" href="http://example.com/path/to/item" />

There is no need to include a rel=canonical link on the canonical page itself. This is a common occurrence, and likely won't have any negative effects since the search engines know to account for it. Specifically, Google has indicated that their crawler handles this case without issue, whereas Bing has indicated they prefer to not see rel=canonical on the canonical page although it doesn't really hurt your ranking if it happens.

Here at Visual Lizard Coda is our go-to development application. It used to be that, when we needed to build a site, we needed a code editor open, we needed an SVN manager open, we needed an FTP program open. Having a single application that handled it all was a milestone; there was the time we were doing things the hard way and there was the time we started using Coda.

When Coda 2 was released, I was one of the first to download it. I was so excited to try Panic's upgraded application that I grabbed it as soon as midnight rolled around. Sure, there was a seven-day trail available at Panic's website for those who wanted to dip their toes, but I grabbed it from the App Store. Buying directly from Panic would give them a bigger cut (Apple taking 30% from the App Store purchases) and probably provide quicker updates (not requiring Apple's approval to push out new versions), but the App Store version comes with iCloud syncing, and I really don't want to rely on remebering where I put all my serial numbers anymore.

One of the first changes I saw was the Sites screen. Sites could now be dragged onto one another to create groups. Since a good chunk of my work involves development servers, staging servers, production servers, etc, this simplified my ever growing project list a lot. Also, I finally had the option to see the Site screen as an actual list! The thumbnail view is certainly pretty to look at, but like the Mac OS X dock, it's prettiness doesn't translate into practical usage, especially when you have dozens of projects. The list view has the extra advantage of showing the site's root URL and last date the project was opened.

A welcome addition to Coda 2 is a built-in MySQL editor. The main thing I like about Coda is that I can develop in one place, and I do a lot of MySQL work. No more alt-tabbing to a dedicated MySQL app or phpMyAdmin. I can open multiple instances in tabs, connect to other servers with host-user-password info, and run arbitrary SQL. This sort of addition reenforces the idea that Coda is made for me and developers like me.

The sidebar has been rethought for the better. It used to be split, with a perpetual file list above and most other options (code help, shared documents) in a smaller space below. Now it is a single, fully adjustable pane. The black floating SVN window (which I was never a fan of) can be there, now feeling a full part of the app. The code helper can be there, having a lot more room to display, rather than the cramped single line in Coda 1. The file can be there, but more importantly, can also not be there.

Overall, Coda 2 is the development application I fell in love with peppered with great updates. Code folding, quick file opening, Trasmit built-in FTP-ing, CSS popup tools, GIT integration, file browser from the path breadcrumb, etc. I'm still discovering little additions that I can now not imagine not having.

Now, since this is the launch of the app, it is expected there will be a couple hiccups. Off the top of my head, these are some of the things we are looking forward to being fixed/improved...

• In the preferences pane, checking/unchecking the iCloud-syncing option sometimes crashes the app
• In the sites list, when I copy the root URL from the site editor, sometimes that field appears blank when you open that site again to edit. The data is there, but its disconcerting to see it blank.
• On the site list, it would be fantastic if I could click or shift-click on something on the root URL to open it in a browser.
• Sometimes, the site list will just "forget" my SVN username and password.
• I also purchased Diet Coda, and I'm hoping our iCloud-synced site list will eventually be available on it.
• When I shrink the toolbar to text-only mode, the already-small favicons the app uses for the Sites tab are sized down to the point of being almost incomprehesible.
• When the toolbar is larger and using the icons, I find the Files icon looks too much like the white-backgrounded code icons of all the other tabs.
• HTML and CSS validation is included, but no PHP? Someone will make a plug-in, I'm certain, but still... darn.

...there's probably more, but I'll let my co-workers chime in on their own. None of these are critical, and they haven't stopped me from making Coda 2 my default editor already. It might sound silly to be this passionate about what application I use to build in, but when you love your work, its hard not to love how you work.

If you visit visuallizard.com with any regularity, you know that we post up interesting links for each other in the Daily Links portion of our blog. A little while ago, we were discussing what we could do to make the posting of these links easier. Posting a link wasn't complicated, but we wondered, "Could we make it easier? How about faster? Maybe both?"

Never ones to shy away from a challenge, we set to work armed with the following goal: how can we make this simpler?

Our current process goes something like this:

1. login to Catalyst
2. visit the blog area of admin system
3. find Daily Links section
4. add a new link and fill in the required fields
5. save

In reality, this only takes 3 or 4 minutes at most. But given our nature, we wanted to try to shave it down to 60 seconds or less. How?

With the above process, no matter what we do, we will always have to do Step #4. There is no way to provide a link without providing some data. Over the years, we have distilled the information needed for links down to a bare minimum: link title, URL, image (optional), description (optional), and appearance date (auto set to the current day). The appearance date is only there so we can cue up Daily Links in the future if we know we are going to be away. This leaves us with the required minimum of a title and a URL in order to post a link.

The next thing we discussed was how most of us consume the web. Of the seven of us in the office, everyone has a smartphone of some sort, five of us have tablets, and all of us have laptops. Since we have ready-built tools for posting from our laptop, and we all have smart/mobile devices of some sort, we decided to concentrate on posting from our phones. What would be the fastest way?

Text messaging would be quickest, and given that we have a good partner in Twilio, we explored this. The problem is the 144 character limit. That is not enough space for some URLs even, let alone a description and title.

Email seemed the better choice. In order to facilitate this, we needed to ensure we had the php-imap functions enabled. Once those where in place, we decided to test our plan by creating a new mailbox that would collect the emails for our Daily Links. Email is pretty simple by nature and we wanted to retain that simplicity as much as possible. We used the subject field as the title, the first line of the body as the URL, and everything after as the description. The final piece is a little secret code for each of us, that when paired with our at-visuallizard-dot-com mail accounts, act as a the security check and allows the post to be published onto the site.

Once we tested everything, we setup a cron job that runs our "read inbox" routine and writes the contents of valid, security-checked emails over to our database. Voila! Quick Daily Links can now be posted from wherever you consume the web.

In our extremely-rough calculations, we have seen link posting times of around 60 seconds with this email routine versus the 180-240 seconds observed with the login-navigate-post routine. That might not seem like a big gain on the surface, but over the long haul you could end up saving an hour here or there, which really adds up.

A few things to keep in mind if you are going to try this on your own:

• Hosting your own stuff certainly helps, as not all hosts will allow you to add functions to php and create virtual paths in your hosting setup.
• Ensure you have at least 2 security checks to validate the emails before you post them. Restricted from-addresses, secret codes, or even manual approval processes.
• Be aware that spelling, sloppy grammar, typos and the like are part and parcel of email, so you should have another tool for editing posted links. We do in our Catalyst CMS, but you shouldn't look to email posting as your only avenue.
• Never publish the email address you want to send these links to. Never!
• Be prepared to destroy and reset your mailbox if/when the spammers find it. This would of course mean modifying all your scripts as well.

If you are a client of ours and you use our Catalyst CMS, we now have a pretty awesome method for posting to it through email. Contact us if this is something you are interested in and we can make it happen. If you aren't a client of ours but would like to be, we are happy to talk to you about anything you might need.

If you, like us, have been using MTS.ca for internet access for one of our connections, you may or may not be aware that MTS has disabled their outbound mail servers. Head over to their site and review their service notice about disabling outbound mail.

What Does This Mean?

If you have your email setup to use MTS for sending email through SMTP.MTS.NET then you have to make a change.

If We Host Your Email

If you are hosted with Visual Lizard you can set your outbound mail server to either mail.visuallizard.com or mail.yourdomain.com.

You will need to provide your full email address yourname@yourdomain.com and your password.

Set the outbound mail port to 587

You should now be good to go.

If You Host Your Own Email Internally

If you are hosting your own email in-house, then you should already have your outbound email servers setup. Talk to your IT person at your company if things have stopped working. They will have more answers than we do.

If You Were Using MTS To Send Email At Home/Work and We Don't Host You

This one becomes a matter of choice. If you have been sending email through MTS from home or work, and this is no longer an option, then you can do a few things

• Check with your hosting provider and find out what information they have for you and how you can send using your domain's outbound mail servers or your hosting provider's mail servers.
   
• Setup multiple email addresses in your Gmail.com account or forward your email accounts to a GMail.com account and then send all reply emails from there with a specific reply-to address. See Google's help on using multiple email accounts with gmail. If you go this route, then you can use Gmail's outbound mail servers, or you can use your website's outbound mail servers to send through.
   
• Update your email account service with MTS to use Live.com email. See MTS' instructions on how to do this.
   
• Switch to a different interent provider that offers outbound mail servers when you are connected to their network. This isn't very practical, but is an option if you want to explore other services.

As always, this is information on the internet. Use at your own risk and hopefully this information helps some of you.

I'm currently using Coda 1.7.4, but I've had a persistant problem across several versions of Coda where the ".ctp" templates in my CakePHP projects would be ignored in the Coda search results. I had things working most of the time by setting up a Custom Syntax Mode in Coda to display ".ctp" files with PHP highlighting. That got things working for most of the search types Coda supports, but when using "find in folder" some of the templates were still ignored.

Eventually I was able to figure out out a way to consistently trigger the issue after noticing that the icon Coda used for the file it was ignoring was not the same as the ones for the files it included. The ignored file had the same icon as an executable bash script, and sure enough when I checked the file permissions the file was marked as executable. After a few tests, I was able to determine that the rule was as follows:

•  If any of the executable flags are set,
•  and the file extension is not known,
•  and the search type is "find in folder",
•  Then the file will not be searched.

That made sense, since it wouldn't do to search through binary files. There's no reason for the template files to be executable, anyway, so the right thing to do  was to change the permissions on the file. But that wouldn't help me make mass changes across multiple files if I didn't know that the file permissions were messed up.

Files ending in ".php", however, are searched even when they are executable, so not all executable files are ignored. How could I set things up so ".ctp" files would work the same way? I tried using a completely made up extension, and it behaved the same way as ".ctp". Setting Coda as the default application to open ".ctp" files and setting a Custom Syntax Mode for ".ctp" files in Coda had no effect. I was a bit lost as to what constituted an "unknown" file extension. Especially since some of my coworkers did not have this problem.

I emailed Panic, the makers of Coda, and they were able to confirm that this was a problem some people had. It was not, however, due to anything in Coda itself. Instead the problem was due to the Spotify service in OS X not indexing certain files. Knowing that, I noticed that Finder reported the file "kind" as "Executable Unix File". So I did some research into how to change that. A quick Google search led me to an article about changing a file's "kind". So I tried the following:

• Right clicked on the Coda app in Finder and selected "Show Package Contents"
• Inside the package is a "Contents" folder, and inside that is a file named "Info.plist", which I opened in a text editor.
• I found the section in that file where PHP file extensions are associated with Coda, and added two new entries to the <array> element <string>ctp</string> and <string>CTP</string>.

After saving those changes, exectuable ".ctp" files could be searched in the same manner as executable ".php" files. Hopefully this will be helpful to other people who are having the same problem.

On October 16th I finally caved and bought myself a tablet. At the time, I had no idea what I might use it for, so I opted for the Asus EeePad Transformer. I picked up the keyboard dock as well, figuring that worst-case scenario I'd have bought an Android netbook.

The last time I owned an actual netbook I didn't care for it. The keyboard was too cramped and the battery life was too low. Plus it had a full-sized power brick, which made it awkward to bring it along for short trips. This tablet doesn't have any of those problems (well, by default it uses a lot of power while sleeping ... but I found a simple solution). The overall battery life is about 8 hours for the tablet, and there's an equivalent battery in the keyboard dock, which should suffice for all-day use. Even if I do let it power down, the power adapter is small, so it's not a problem to take it with me. Charging is a bit slow, and the charging cable is both short and proprietary. Not ideal, but I can live with it.

I've found that I prefer using this device in tablet mode for reading and casual web browsing. It's like owning a book with the internet in it. Mostly I've been using it to read comics. I've read comics on my computer before, but it's hardly ideal. For daily webcomics, a browser is fine but longer stories are a nuisance. The tablet, however, is perfect for long-form reading. Ebooks are next on the list to try ... but I'll need to finish off some of the dead-tree novels on my coffee table first.

There are a few quirks I'm still getting used to. The first thing I noticed was that while in-use battery life was fine, the battery level dropped significantly when the device was left in sleep mode for an extended time. Looking at the battery use history it was apparent that the device was waking up and connecting to WiFi periodically. Most likely to check for email, application updates, and probably the time and weather. This was despite having set the device to disconnect from WiFi when the screen shut off. Installing Auto Airplane Mode helped a lot. Now when I wake up the battery is only 1% or 2% lower than when I went to bed. Much better than the 30% drop when the device is allowed to connect to the network from sleep. There are at least two applications named Auto Airplane Mode, so this is clearly an issue that other Android users are having. The one I installed triggers when the screen shuts off, the other one I saw worked by specifying times to turn off wireless access.

The second issue I ran into was when I bought a bag this weekend so I could carry the thing around here and there. Due to the enormous disparity in popularity between the iPad and Android tablets, most cases and accessories for tablet owners will be iPad-specific. And since my particular tablet is decidedly longer than an iPad, it turned out to be a tight fit. But it will keep my tablet out of harms way when I start shuffling it back and forth to coffee shops during NaNoWriMo. I'm sure I'll fail yet again, but I should at least figure out if I like the keyboard.

Mark Pilgrim, a long time voice on the internet and author of many of the sites we have visited over the years, has pulled the switch and removed all his digitial works. Every last one of them has gone dark. 

Apprently this has kicked up a search, headed by Eric Meyer - see his post - that led to the police being called. Which, in reality, is a good thing. There is precedent that software developers / programmers can suffer burn out and then commit info-cide followed by suicide. Wikipedia page (considered for deletion) with a list.

Right now, this entire thing is a little bit of drama on WWW, but it sure feels alot like _why's disapparence in 2009. 

If you are a fan of Mark's work (and you should be), some of his stuff is now being mirrored on GitHub. Here are a handful of links:

• Dive into Mark - https://github.com/diveintomark

• Dive Into Python 3

• Online: http://diveintopython3.ep.io/

• GitHub: https://github.com/diveintomark/diveintopython3

• Dive Into HTML5

• Online: http://diveintohtml5.ep.io/

• GitHub: https://github.com/diveintomark/diveintohtml5

To Mark, thanks for all the words. The internet is a better place for most people because of the work you helped us produce. Here is to finding what you are looking for. Cheers.

I was able to get a Google+ invite late last week and gave the new social network a run over the weekend. Now, a couple days later, I'm finding myself ignoring it. There are a lot of interesting ideas in it, but that is its main problem; there are a lot of pieces that have a lot of potential, but the whole doesn't do anything better than it's main competitor. In fact, it seems to go out of it's way to make it more cumbersome in many places.

Lots of what we see already exist in their own bubbles, have their own branding, and use their own user profiles. Only the over-arcing google login really kept them associated in any way; each app was bought and/or developed with little worry about how it would actually work with the other apps until later in their individual lifecycle. It took months for Youtube and Google logins to be merged, Wave was Gmail and Gchat and Buzz mashed together, Analytics was still using the term "urchin" in their supplied javascript code for years. Hell, depending on which apps you were using regularly, you had two or three completely different "google profiles".

Google+ is, basically, a variety of separate Google apps and products finally pulled together under a core umbrella. Even though there is a strong design and focus behind it, it still has that frankenstein bolted-together feel to it.

One of the obvious elements of this pasted-together development is on what used to be Google Profiles, the Google+ public profile page. There, by default, are the new "posts" and off to the right is the much-ignored "buzz", which is Google Buzz. Aren't these two things almost the same thing? Why didn't Google Buzz inherit the rest of what eventually became the "post" functionality? And how much of the "photos" tab is just half-cribbed Picasa (soon to be Google Photos) functionality?

I probably wouldn't find the whole thing so cumbersome if the core of this social network, the facebook-y parts, didn't try so damn hard to out-facebook facebook. 

The idea of circles is pretty good on paper, but the execution comes across as something designed by a person who only used it as it developed. I came from facebook, and though I can see they were trying to make the transition from a single pile of friends to infinite number of overlapping groups, they only succeeded in making a novel idea annoying.

The rotary-dial grouping for drag-and-drop is one of the too-clever ideas that works best in a photoshop mock-up than in actual practice... probably one of the reasons why this metaphor is not used anywhere else in any app; they just default to text lists everywhere else. Also, the little rectangle profile cards had a troublesome problem with being recursive, where hovering on a name within them would open another rectangle, which had links that would open other rectangles, three or four deep.

The hovering rectangle issue seems to have been resolved since last week, thankfully. This implies that it is one Google app that actually deserves the "beta" label, even though it's the first in memory that lacks it. Or won't be wearing it for four or five years.

Despite all this, I'm absolutely certain Google+ is going to be successful. First of all, there's several people who will jump on it simply because "it's not facebook". It's gotten to the point where hating trends and/or fads has become a trendy fad in and of itself.

Second, there are going to be people who want a social network that lets them be less social than twitter or facebook... now you can group people in cliques and make sure the right people never see that other group you hang out with. 

Finally, that heavy promotion of the +1 button means search engine opimization experts the world-wide-web over will be pushing all things Google on their clients. Where web apps like Twitter became popular due to a focused and vibrant community that grew, Google+ will be rammed down our throats by a combination of Google corralling all their free apps into it and SEO advice being laid on thick, bribing site developers and owners to support it in return for better ranking.

I'll probably keep poking at it over the next couple weeks simply because it does have so much potential in it's parts. But until the whole starts doing things as well as or better than Facebook, I'm having a hard time justifying bothering maintaining both... and facebook was here first.

After all, remember Orkut?