Just when you think you’re Googling the same old way, Google switches it up. They recently rolled out the new SERP look and feel, which really just adds more tools and functionality to the search engine results area without your permission. These tools were accessible before, but only if you wanted them. Now they take up space and really clutter up the results page. This wasn’t necessarily a good move for Google, as it makes them more like Yahoo! and Bing. It definitely gets away from their clean look and simple focus on search. The irony is that they made a change a couple months ago where none of the other links or information showed up when you first loaded Google, but if you moved your mouse around everything would fade in.
It appears others are not that thrilled either. If they had a “classic” version, that would probably get a warm welcome. Or at least the ability to hide the left-side navigation.
In case you didn’t hear last week, Steve Jobs told Adobe what’s up. Flash was a necessary evil, back in the day, to make interactive websites possible. The downside has always been that you have to install a third-party browser plugin in order for the Flash content to display. For entire Flash websites, this means that you can’t view anything unless you have the plugin.
Search engines can’t even index the content on a Flash website very well, if at all. With HTML5, CSS, and JavaScript, any modern web browser natively supports most of the interactivity that used to require a special Flash interface. Animations and other cool effects can be done with JavaScript. Even video streaming doesn’t require Flash any more.
Flash was essentially a way for developers to do things that web browsers weren’t ready for yet. It was a hack, for the time being. The big difference is that now content doesn’t have to be encoded into a movie file that only a proprietary plugin can play. Web content should adhere to open standards, making it available to any platform, and that’s the point that Steve Jobs is making.
Basically, Flash is obsolete.
Google has renamed the Google Local Business Center to Google Places and added even more useful functionality. One of the coolest things about Google Local Business Center “upgrading” to Google Places is the fact that businesses in select cities (larger ones at the moment) can request a photo shoot of their business for free.
Some other new features include:
- Hide private street addresses for businesses without storefronts or offices
- Simple advertising with Tags to highlight your business for a very low monthly cost
- Coupons formatted specifically for mobile phones
- Customized QR codes, which are scannable bar codes that let people bring up your Places profile on their mobile phones
These QR codes are already popping up all over town. It’s interesting to see how much influence Google has in the offline world, too.
Among the reasons to have your website load quickly, the latest one will help your search engine performance. Google announced it would be factoring website speed into it’s search ranking algorithms.
It’s a good idea to have a fast website regardless, to keep your visitor’s attention easily and improve their experience, but now Google is taking more notice and giving you high marks for the “site speed” category.
There are a number of ways to speed up your website, but the most important include:
- Use XHTML/CSS so your content downloads quickly
- Make sure images and other media files are optimized for the web in terms of file size
- Avoid heavy use of Flash, video and image-based design
- Combine JavaScript and CSS files to reduce number of file requests
- Compress code using GZip on the server
- Pick a reliable web hosting company that doesn’t overcrowd its servers or oversell its resources
Yahoo has put together an extensive list of best practices for speeding up your website that’s definitely worth a look.
This is a great addition to Google’s search ranking method, because it ultimately means a better user experience. In an era of impatience, only the quick survive.
You can easily create a Slamdot-specific browser for your Mac OS X desktop with Fluid and the high-resolution logo provided below. We got the idea from our friends at 37signals and wanted to join the fun!
You can find more great icons for other web apps at the Flickr group for shared Fluid SSB icons. Very cool.
With the recent announcement of the long-awaited IMAP functionality available from Google, we’ve had a lot of customers asking how to go about setting up Google Apps to work with Slamdot. So, let’s get this party started, shall we?
Step 1: Sign up for Google Apps
If you haven’t already done so, you’ll need to first sign up for Google Apps. There is a free plan that will work well for most people.
Assuming you already have a Slamdot account, you’ll already have a domain name to use with Google Apps. So, on the first step of the signup process, make sure that you enter the domain name that you’re using with Slamdot into the existing domain field. The rest is pretty self-explanatory.
Step 2: Verify domain ownership
Once your account has been created, you’ll receive your login information and instructions for verifying your domain ownership. We recommend that you simply upload the HTML file that Google Apps generates to your public_html folder. This is by far the quickest and easiest option to get up and rockin’ right away.
Step 3: Enable services for your domain
Now that your account has been created, you’ll need to turn on the services that you wish to use from Google Apps. For example, you might choose to enable Gmail, Calendar, and Docs & Spreadsheets for your domain.
You probably won’t need to enable Google Page Creator since your Slamdot account includes web hosting space for your web site, including more powerful features like PHP, Perl, and Ruby on Rails to give your site a dynamic backend.
You should setup custom web addresses so that URLs like http://mail.yourdomain.com and http://calendar.yourdomain.com redirect to your Google Apps hosted applications.
If you’re going to allow Google Apps to handle your email hosting, go ahead and setup email accounts for any users that you created under Slamdot. In the next step, you’ll be routing your email to Google Apps, so you’ll want to make sure it’s ready to accept your mail.
Step 4: Modify your DNS settings at Slamdot
At this point, you’ve enabled the services that you want to use from Google Apps. Now you need to configure Slamdot to allow Google to take over email hosting, as well as setup any custom web addresses you created.
First, log into your Slamdot account with your email address and password (or OpenID). Click on your hosting plan from the Dashboard to access its Control Panel. Next, click on the Advanced tab and proceed to the DNS link.
Here, you’ll need to remove any existing DNS records that may conflict with your custom web addresses that you created. For instance, Slamdot automatically created an MX record and an A record, called mail, by default when you signed up. If you’re going to be hosting your email with Google Apps, you’ll need to remove the existing MX record first by clicking on the trash can icon next to the record. If you used mail for your custom web address, you’ll also need to remove the existing A record for mail.
Now you need to enter the CNAME and MX records provided by Google Apps.
If you’re allowing Google Apps to take over your email hosting, then you need tell Slamdot not to worry about it any more. To do that, simply click on the Email tab and then click on the Edit Email Settings button on the right-hand side.
Toggle the radio button next to the word No and you’ll be all set. Click the Update email settings button to save your changes.
If Google Apps will be handling your email, go ahead and remove any existing email accounts at Slamdot. You can also delete any forwarders, mailing lists, autoresponders, or vacation messages you setup since they will no longer be necessary.
Step 5: Have fun with Google Apps!
Once Google Apps has verified that you’ve configured your DNS settings properly, your services will be provisioned. After a few moments, you can start playing around with the various services you enabled. If you’re using Google Apps for your email, you’ll need to reconfigure your desktop email software to use Google Apps for POP or IMAP access.
Should you have any trouble getting Google Apps to play with nice with Slamdot, shoot us an email and we’ll be happy to lend a helping hand. Good luck!
On our way to a more RESTful Slamdot, we ran into a slight snag with the way Rails’ routes were being generated by Resources. We needed to be able to pass the user’s currently active domain name as a part of the URL, which turned out to be a little more difficult than we had hoped.
According to the Rails 1.2 RC1 release notes, the solution was simple:
Action Pack has an all new implementation of Routes that’s both faster and more secure, but it’s also a little stricter. Semicolons and periods are separators, so a /download/:file route which used to match /download/history.txt doesn’t work any more. Use :requirements => { :file => /.*/ } to match the period.
Only not so simple. At the time of this writing, resources don’t allow for a :requirements option to be passed on to the routes being generated. So, using Jamis Buck‘s incredibly-useful articles about routing, we were able to monkey-patch Routing to do exactly what we needed.
The code
module Slamdot
module Routing
module DSL
module MapperExtensions
def self.included(base)
base.alias_method_chain :connect, :domain
base.alias_method_chain :named_route, :domain
end
def connect_with_domain(path, options = {})
options[:requirements] = { :domain => /.*/ } if path.include?(':domain')
connect_without_domain(path, options)
end
def named_route_with_domain(name, path, options = {})
options[:requirements] = { :domain => /.*/ } if path.include?(':domain')
named_route_without_domain(name, path, options)
end
end
end
end
end
ActionController::Routing::RouteSet::Mapper.send :include, Slamdot::Routing::DSL::MapperExtensions
What it’s doing
We make use of the alias_method_chain idiom to wrap our custom connect_with_domain and named_route_with_domain methods around Rails’ default behavior. So now, when our routes are being generated, we intercept them and inject our :requirements option (if necessary). Then, we sneakily hand the route construction back over for completion.
That’s all for now!