Thanks @AvinashKaushik for the link - it's old but it's good! For some of you, this will be a flashback, for others it will (hopefully) provide first time inspirations. Here are a few of my favorites:
Thanks @AvinashKaushik for the link - it's old but it's good! For some of you, this will be a flashback, for others it will (hopefully) provide first time inspirations. Here are a few of my favorites:
The good news that I found is that Rails’ I18n support is pretty great. The bad news is that it is overly integrated with the rest of Rails, making changing it in isolation difficult.
There’s a great Rails Guide on internationalization that’s required reading for anyone trying this at home. My brief nutshell of an explanation is that you create a Ruby or YAML file under config/locales that has a set of hashes of hashes pointing to a specific key. An example would be { 'en' => { 'activerecord' => { 'errors' => {'blank' => 'is required' } } }. That sets the English translation for the key activerecord.errors.blank to “is required.”
You can set your Rails application’s default locale like so:
I18n.default_locale = :es
That will set it to Spanish. There’s not a definitive list of locales, so you could use :lolcatz or :morlock and it will work fine. You set the locale in a specific request like this:
I18n.locale = :es
When you do that, all keys called via I18n.translate (accessible as t in views because of helpers) will return the Spanish translation.
Overall, this is simple and easy. We found this to be helpful not only for Spanish translations, but setting English text as well. You can set the human-readable names of your ActiveRecord models and attributes through this facility, which is very nice for creating forms, especially with Formtastic.
Reading these YAML and Ruby files and holding the translations in memory is the job of the class I18n::Backend::Simple, which is what’s written on the box: a simple backend for the I18n service in Rails. If you want translations to be editable by non-programmers, though, YAML and Ruby files won’t cut it.
It is easy to extend Simple or write a new backend. Once you’ve written one, you can tell `I18n` to use it:
I18n.backend = I18n::Backend::SnippetBackend.new
I wanted to store my translations in the database and knew I’d only have English and Spanish translations forever. If you’re supporting multiple languages, you’ll obviously want to add another model to the following code. Here’s the backend I wrote:
module I18n
module Backend
class SnippetBackend < Simple
protected
def init_translations
load_translations(*I18n.load_path.flatten)
load_translations_from_database
@initialized = true
end
def load_translations_from_database
data = { :en => {}, :es => {} }
Snippet.all.each do |snippet|
path = snippet.name.split(".")
key = path.pop
en = data[:en]
es = data[:es]
path.each do |group|
en[group] ||= {}
en = en[group]
es[group] ||= {}
es = es[group]
end
en[key] = snippet.english
es[key] = snippet.spanish
end
data.each do |locale, d|
merge_translations(locale, d)
end
end
end
end
end
This code pulls all the translations I have stored as Snippet models out of the database and merges them into the translations already loaded from the YAML and Ruby files. The only piece of magic here is splitting the key's name. The period syntax to indicate nesting is used in the keys normally, so I continued it in my snippets. To make this match the data from the YAML and Ruby files, I have to transform it into nested hashes.
I also used a plugin called Typus for an administrative interface in this application. It’s a great plugin, and I can recommend it if you want a Django-style interface for editing content without a lot of fuss.
When displaying a list of your editable models, it pluralizes those models’ human names; for example, EmergencyContact becomes “Emergency contact” and is then pluralized to “Emergency contacts.” This works perfectly with English. However, when using Spanish, I ended up with a slight problem:
>> EmergencyContact.typus_human_name
=> "Emergency contact"
>> EmergencyContact.typus_human_name.pluralize
=> "Emergency contacts"
>> I18n.locale = :es
=> :es
>> EmergencyContact.typus_human_name
=> "contacto de emergencia"
>> EmergencyContact.typus_human_name.pluralize
=> "contacto de emergencias"
“Contacto de emergencias” means something like, “a contact for lots of emergencies,” which wasn’t my intention. What I need is “contactos de emergencia,” which would require Spanish pluralization rules. The Rails pluralization rules are based on English. That made sense to me, so I could go add pluralization rules for Spanish, just like you can add translations for Spanish, right?
Unfortunately, that’s not true. Inflection rules in Rails don’t take multiple languages into account, so you can’t define new ones for a particular locale.
Quixotically, I decided to fix this. Here’s the code I ended up with:
module Inflector
# Yields a singleton instance of Inflector::Inflections so you can specify additional
# inflector rules.
#
# Example:
# ActiveSupport::Inflector.inflections do |inflect|
# inflect.uncountable "rails"
# end
# Original method
def inflections
if block_given?
yield Inflections.instance
else
Inflections.instance
end
end
# My crazy method
def inflections(locale = nil)
locale ||= I18n.locale
locale_class = \
if locale.to_s == I18n.default_locale.to_s
ActiveSupport::Inflector::Inflections
else
ActiveSupport::Inflector.const_get("Inflections_#{locale}") rescue nil
end
if locale_class.nil?
ActiveSupport::Inflector.module_eval %{
class ActiveSupport::Inflector::Inflections_#{locale} < ActiveSupport::Inflector::Inflections
end
}
locale_class = \
ActiveSupport::Inflector.const_get("Inflections_#{locale}")
end
if block_given?
yield locale_class.instance
else
locale_class.instance
end
end
# Returns the plural form of the word in the string.
#
# Examples:
# "post".pluralize # => "posts"
# "octopus".pluralize # => "octopi"
# Original method
def pluralize(word)
result = word.to_s.dup
if word.empty? || inflections.uncountables.include?(result.downcase)
result
else
inflections.plurals.each do |(rule, replacement)|
break if result.gsub!(rule, replacement)
end
result
end
end
# My method
def pluralize(word, locale = nil)
locale ||= I18n.locale
result = word.to_s.dup
if word.empty? || inflections(locale).uncountables.include?(result.downcase)
result
else
inflections(locale).plurals.each do |(rule, replacement)|
if replacement.respond_to?(:call)
break if result.gsub!(rule, &replacement)
else
break if result.gsub!(rule, replacement)
end
end
result
end
end
end
This code is pretty complex, but there's only three major changes to the original methods. First, I added the ability to pass in a locale to use on each method, and made the current locale the default one. Second, I changed the behavior of the Inflections class. Instead of having one singleton class, I have a lot of singleton classes, each associated with a locale. These classes are created dynamically through a module_eval. Lastly, I added the ability for inflection transformations to be lambdas instead of just strings.
If you’re shaking your head and asking, “did he just create a new class for each different locale?”, I don’t blame you. It’s a little crazy. Believe it or not, this works magically, though! Here it is at work:
ActiveSupport::Inflector.inflections(:es) do |inflect|
inflect.plural /$/, 's'
inflect.plural /([^aeioué])$/, '\1es'
inflect.plural /([aeiou]s)$/, '\1'
inflect.plural /z$/, 'ces'
inflect.plural /á([sn])$/, 'a\1es'
inflect.plural /í([sn])$/, 'i\1es'
inflect.plural /ó([sn])$/, 'o\1es'
inflect.plural /ú([sn])$/, 'u\1es'
inflect.plural(/^(\w+)\s(.+)$/, lambda { |match|
head, tail = match.split(/\s+/, 2)
"#{head.pluralize} #{tail}"
})
end
You'll notice that lambda in there: I added that ability so that I could transform the first word in a string instead of the last.
The above works a little too magically, however. The pluralize method is used everywhere, particularly in changing model class names to table names. As you can imagine, I started seeing errors like “No table found with name emergency_contactes.” I spent a good day running into similar issues and fixing it with code like:
# Create the name of a table like Rails does for models to table names. This method # uses the +pluralize+ method on the last word in the string. # # Examples # "RawScaledScorer".tableize # => "raw_scaled_scorers" def tableize(class_name) pluralize(underscore(class_name), I18n.default_locale) end
Note that I called pluralize explicitly specifying that I want to use the default locale, which would be English. This is a simple fix, but I ended up having to repeat it multiple places in ActiveRecord, ActiveSupport, and ActionController.
First, even though this post’s talked about issues I had, the I18n support in Rails rocks, and I’ve found it to be a bit of a universal solvent for form issues, which I hope to talk about in another post. The ability to add new backends is nice, and the combination of my backend and Typus is hot.
I’ve learned that Rails’ inflections are used throughout the framework and trying to reuse them for automatic pluralization and singularization of non-English languages is hard. I think the results might be worth the effort, though. The translation system does have the ability to define singular and plural names for things, but they don’t work through pluralize, so you’d have to re-write how you generate plural names for model objects. That’d be more local than my sweeping monkey-patches, however. Looking back over my code, I’ve decided that it is full of red flags, but not altogether misguided.
How are you using Rails’ I18n? Have you had problems? Are the above fixes terrible hacks or awesome hacks? Let’s talk in the comments.
(You can see all the code from this post at http://gist.github.com/138956.)
]]>
Back in January, Doug let the ... uh ... bear out of the bag, so to speak, with his post about using geometry in design. In it, he showed his design process for the Pointless Bear -- the mascot of Pointless Corp. What's Pointless Corp. you ask? Well, it's neither pointless nor a corporation. But, first, some history.
Ever since we started Viget almost a decade ago, people have often said "you guys have all the talent to build web apps -- designers, developers, marketers -- and you must have ideas. Why don't you launch your own products?" It's a fair question with a simple answer: we don't want to be a product company. Our goal at Viget has always been to be a great consulting company, working with great clients on a wide variety of interesting projects.
Consulting isn't easy. There's a ton of work that goes into all aspects of the business, including traditionally boring things like accounting and operations and interesting things like how you can closely collaborate with clients with methods that are customized enough for their needs but still structured enough that you can count on the results. The standard advice we all give start-ups is to focus. Without focus, a business has no hope. At Viget, our focus has been consulting, and trying to build products would put that focus -- and our success -- at risk.
That's not to say we haven't built our own stuff. Like most web shops, we built our own content management system in 2002 (since phased out). Being open source advocates, we're constantly contributing code to the community. When we have time between client projects, we're always playing with new technologies and ideas in one way or another. Even with all that, we felt that we could be more effective with our downtime, learn more from our experiences, and become better consultants providing more value to our clients if we had a more structured approach to internal projects.
Pointless Corp. is a way for our teams to rally around an idea and work together to launch a web app independent of client work. It's not an original concept, but I think we have a slightly different take on the approach.
The name was inspired by Harry Nilsson's story The Point! which includes a character called "The Pointless Man" who said "a point in every direction is the same as no point at all." We want Pointless Projects to take us in all kinds of experimental directions.
More importantly, the name is a constant reminder about focus. The focus of Viget is working with great clients to build great products and web sites. That's our point. Pointless Projects themselves are far from pointless, though -- they're a chance for us to learn about technologies and processes, to grow and experiment with new ideas, to share and contribute to the web community, and to have fun working together in tight teams. But, were we ever to prioritize Pointless Projects over client work, we'd be putting everything we've accomplished thus far as a company at risk.
We're proud of what we've done so far at Viget as a consultancy, and we've still got a long way to go. By launching fun, useful projects under a different "brand," we don't have to worry as much about people misunderstanding Viget's purpose.
We've kicked around lots of details internally, but I'll cut to the chase:
We've learned some good lessons there too, but that's for another post.
So far, we've launched four official Pointless Projects:
Each one had a different team, approach, schedule, outcome, and set of lessons to apply to the next one. We have a few more in the hopper at various stages of completion. If you're interested in what we're working on, you can check out the Pointless site (currently just a blog), follow Pointless on Twitter, or keep an eye out here at Viget. We'll make sure to spread the word about any big things happening. If you have any questions or ideas about Pointless, please drop a comment below or contact us.
]]>Now, instead of going into the Reports Tab, you can simply navigate to an ad group (or look at the entire account) go to your keyword tab, select the keywords you wish to run the report for and then click the “See Search terms…” dropdown.
AdWords will then display a pop-up of the search query report for your selected keywords, in real time. From there, you can see what search queries your selected keyword triggered, and easily add or negative out that keyword from your campaign. Last month Google even got rid of the “other queries” bucket that previously encompassed all search queries that did not generate enough clicks, thus leaving out valuable search query information.
Why is this so great? Aside from the fact that it gives you great insight into what visitors are searching for surrounding your keywords, it makes the whole process of running the report much more efficient. No longer do you have to go in to the reporting tab, run the search query report, wait for the report to process, and possibly export the data into a spreadsheet. Of course, if you ever needed to do that it is still an option.
So far I’ve used the new search query report for several clients now and I’ve been hit with interesting, funny, or surprising results. Each time I’ve taken these results and utilized them to improve the campaigns. If you haven’t run the new search query report on your campaigns yet I strongly suggest doing so. Who knows what you may find!
]]>
Viget's Durham office facilitates Refresh the Triangle each month, and if you're local to the area you should have been in attendance last night. Robbie Allen, sole founder and CEO of the StatSheet Network, spoke about his experience running a web startup in the Triangle area. Here are my top three highlights from the talk and why the meeting was one of our best yet.
Highlights from the talk:
Why the meeting was one of our best yet:
Congrats to Robbie Allen for recently being awarded a NCIDEA grant. As he pointed out, we're lucky to live in a state with such a cool grant program for startups. Anyone know of other states with similar programs?
Refresh the Triangle meets on the fourth Thursday of each month. See you next time!
]]>Even worse, maybe you're only delivering a sliver of the site, just one or two pages, and this team will need to finish out the other 90% of the markup. You'll be credited with the buildout or blamed for it, but the final results are out of your hands. What do you do?
Or, imagine that you're a client who's hired Fancy Design Firm to design the site, and you want your Stressed-Out Internal Team to develop it. You need to make sure that S.O.I.T. can correctly implement the stuff you get from F.D.F., and you even want them to expand on it, stretching the design into a full site with new styles.
The trouble? You don't know how F.D.F. codes or what to expect from them. Whatever you get from them will be final - you can't go running back every day until launch and asking them for stylesheet tweaks. You're not a CSS/HTML expert, so you're not sure you'll be able to tell what's good or not. What do you do?
Both parties are in a spot here: Designers are hoping their work doesn't get mangled, and clients are hoping their deliverable isn't crappy and inflexible, but neither party has a sure-fire way to get what they want.
I've been delivering buildout a lot recently, so I've been reflecting on what works best in this situation. In the interest of helping designers and clients agree on deliverables, I've written this little reference list. This is by no means a "client bill of rights," simply a set of topics clients and designers should discuss when expecting a CSS/HTML deliverable.
Reusability - Styles should be named and implemented with re-use in mind. Simple utility classes like "right", "left," "intro," and "hide" let clients quickly achieve design effects, and more specific classes like "feature-set" can be reused sitewide and modified to client needs. In contrast, "fall-2009-promos" is a dead class: a set of styles that the client will need to basically rewrite in order to copy.
Note about semantics: While classnames should be semantically meaningful whenever possible, clients will run into situations where their boss just asks them to float a photo to the right. Rather than making them add a ".secondaryPhotoArticle" class to the stylesheet, I'd rather give them something meaningful to THEM, like ".right."
Documentation - A designer's first instinct might be to leave comments in the code, but these tend to get ignored and bloat the filesize. Any buildout deliverable needs some kind of documentation of how the more complex elements interact, and offer ideas on how to reuse or change them.
Quick tip: Sometimes we hand off sites with an "element list" page,
which has all the site's major components laid out on a single page
with notes. Developers can mix and match elements as they please, instead of trying to copy pieces from finished designs.
Design Files - Nothing is final on the web, and the PSDs received from a designer should reflect this. At the very least, they should still have slices in place, but major images and sprites should be broken out into files that can be easily tweaked and Save-For-Webbed.
Quick tip: I've found that breaking elements into individual PSDs is a huge help during the buildout phase itself — it makes quick adjustments a snap.
Styles for Every Tag - Even if the design doesn't have a <dl> or <table>, for example, it needs to anticipate one with some simple styles.
Quick tip: I actually use a class of ".data" to style tables, just in case
clients need to use a table for layout or import some existing tables. In a perfect world, clients wouldn't use tables for layout, but designers need to design for imperfect situations.
Validating Markup - The final markup validate, even if it won't be perfectly valid on the final site (due to outside plugins or requirements). This is a simple way to check for bad markup, as well as a way to tell if designers are working with web standards in mind.
Bugs - Everything should be built for flexibility, but between handoff and launch, there's always going to be something the design just didn't anticipate. If the client doesn't have the technical expertise to work on these bugs, they should consider keeping 10-20 hours of support time on the contract for help during the development phase. (Actually, put this time on the contract regardless!)
IE6 Support - Sorry designers, but clients should expect that you tested everything in IE6 and got it running. Clients, install something like MultipleIE to check this out for yourself.
IE6 Perfection - Nothing should look broken in IE6, but it won't look exactly like the comp. There are some visual touches that are just too time-intensive to implement in IE6, and quite frankly not worth the time a client pays a design firm for.
Hyper-Changeable Design - There's no way around it - some things are just going to be a pain to change. Graphical navs and big backgrounds tend to be time-consuming to update, so if clients anticipate new nav items or color changes a month after launch, they should let the designer know early in the process.
"Our Internal Designer Will Finish It" - Javascript and CSS, while familiar to most designers, might not be a strength that a client's in-house designer has. If the designer needs to make major changes to complex pieces of the site (an image carousel, for example), make sure everyone knows up front, and make sure the internal designer talks to whoever's doing the buildout. This also goes for Photoshop effects: if a client expects to copy a designer's style month after month, they should ask for a tutorial on the style.
No one's off the hook here: In order to get a good, appropriate buildout deliverable, both parties need to set expectations and be ready to make compromises. These guidelines are just a starting point. So what do you think? Did I miss anything, or put something in that you absolutely disagree with? Let me know in the comments.
]]>In addition to program-related content, PBS Education offers professional development courses and communities along with independent national services like PBS Kids Island. The PBS Teachers web site faces the challenge of helping PreK-12 educators navigate these rich resources - across all PBS program and station sites - to find just what they need for their current lessons or professional development needs.
While a primary goal of the redesign was to establish a consistent browsing experience that could scale as new resources and services were added, PBS Teachers also needed a fresh look to fit in with the new PBS brand strategy. Viget had the great privilege of working with the good folks over at PBS Education to tackle this redesign, and we're pleased to announce the launch of the new PBS Teachers site!
]]>Brightcove offers a wide range of players that will plug right into your site. Its players range from a video window with basic controls to players with tabbed navigation, playlists, related videos, and keyword search. These players are easy to build into your site and connect with videos you've uploaded to Brightcove.
Unlike most drop-in players, Brightcove offers a great deal of customization. You can style existing players using a video player editor where you primarily have control over colors. This goes a long way when you're trying to match the look of your player with the look of your site, but you can take this a step further with a proprietary markup language called BEML (Brightcove Experience Markup Language). Think of BEML as HTML for a media player. You add custom images to replace the Brightcove custom elements (like your play or mute button for example). You also have complete control over which Brightcove components you want for your players and even which buttons you want for your player controls (play button, mute button, etc.).
However, even with base color styling and more advanced BEML modifications, you may still run into styling and component limitations. If you want to really customize your player, Brightcove allows you to take things even further with their API. So, with said API, Adobe Flex, and custom UI and visual design up front, that's what Viget did ...
Recently, a client who was using the Brightcove video hosting platform to house their comprehensive video library came to us with concerns. They were not completely satisfied with how the players looked and they wanted more functionality than what they were getting out of the existing player components.
The first and main concern was that the components (like tabbed views of custom lists of videos) were not making their videos visible enough. The second concern was that the look of the players weren't customizable enough and the client felt like they weren't getting the visual integration they needed with the rest of their site.
The player we created consists of two views. In the first view, we needed to take into account the large number of videos, so the goal of the design addressed choice and selection. On the main video dashboard page, the user can see a truncated selection of videos in the "Featured Videos" and "Most Watched Videos" sections. Below that, the user gets a wider selection of videos via the "Recently Added", "Highest Rated", "Media Appearances", and "This Week" filters. Not counting the search, a user is only a few clicks away from about 350 videos in this view. This doesn't cover every single video, but it does make every category of video immediately visible.
In the second view, there are numerous video choices as well. However, since the user has selected a video to get here, we understand that the main focus should be the video itself and the videos related to it. Aside from the current video playing, there is a list of approximately 50 videos that relate to the chosen video.
To keep available video options accessible, this view offers an expandable view of the four main sections of video by clicking "View More Videos" at the bottom. Here is the wireframe of that view.
With the UI nailed down, we were able to apply the font, colors, and styles needed to visually integrate the player with the client's site and brand.
Ultimately we implemented two players. The first player is the large media console that has been shown, the second is a standalone player used for displaying single videos or embedding videos on other sites. All data was accessed with simple calls to the Brightcove media API. With the exception of the "Most Watched Videos" list (which is compiled by Brightcove video analytics), all video sets are being pulled in as existing playlists that have been set up within Brightcove.
We've been quite happy with the results, and we'll be eager to share the final product with you when the site goes live. We wanted to go ahead and share the find though, as we know (from experience) that the search for such solutions is an ongoing and often frustrating one. It seems that Brightcove is offering just what's needed to go anywhere you want with custom video players. From quick-and-easy, lightly-styled approaches to fully customized players, the options and flexibility are rather nice.
]]>The concept of “Branded Utility” isn’t new (we wrote about it here and here), but it's still in its infancy and by no means has it been widely accepted, or widely disseminated -- we're hoping to help change both of those things! Enjoy the slideshare!
]]>You can buy an iPod nano on Apple, Best Buy, etc. for about $149. Amazon sells it for $134. That’s probably cost price. It turns out that Amazon can sell almost everything at cost price and still make a product because of volume. It’s all down to the Negative Operating Cycle. Amazon turns over its inventory every 20 days whereas Best Buy takes 74 days. Standard retail term payments take 45 days. So Best Buy is in debt between day 45 and day 74. Amazon, on the other hand, are sitting on cash between day 20 and day 45. In that time, they can invest that money. That’s where their profit comes from.
Holy smokes. Maybe I'm dense or out of the loop on these things, but while I figured there was a volume advantage to Amazon, I didn't realize that this cycle-based plan was the key to their profits.
Barn and I were talking about this a little over IM today, and this gives a lot of fun fuel with which to speculate about all things Amazon.
The first question is: how stable is this kind of model? Will vendors start shortening the cycle on Amazon, knowing that Amazon is able to pay more quickly? My guess is probably not. If vendors are widely accustomed to the 45-day terms, and Amazon is providing a large portion of their sales, then everyone is winning. I can see pressure coming from vendors who are also retailers, like an Apple, in an effort to keep Amazon prices in line with the rest of the industry, but it's probably likely to stay put on the whole.
As a follow-up to that, if Amazon is dependent on the returns it's getting on these investments, is the down market strongly impacting them? You have to guess that it would, but their Q1 2009 revenues and earnings are up year-over-year compared with Q1 2008. Even if their returns are lower on these investments, their lower prices may be working really well at bringing in increased sales in this recession, where consumers are more price-conscious than ever. They are indeed growing slower than they were in this economy, but they're still the best on the block.
How can brick-and-mortar operations like Best Buy compete with Amazon when Amazon can sell at cost all they like? Best Buy relies on two things in competing with Amazon:
Amazon can lessen the impact of the former by making returns even easier and lower-risk than they do now. Taking cues from Zappos, which has made buying clothes and shoes online almost risk-free, could help make this happen. A broader return policy (many items cannot be returned to Amazon if they've been opened) and free/cheap return shipping would be enough for the vast majority of consumers.
The latter is much harder, and is probably where they're less likely to try to compete. But can businesses like Best Buy rely largely on that immediacy as an advantage? It seems very relevant to incidentals and consumables like office supplies, blank CDs, and even books/music/movies (if you don't have a Kindle, TiVo, or Apple TV), but folks can usually wait a day or two for a pricey consumer electronic product in exchange for a discounted price.
I actually think that Amazon is more than happy to stay out of the storefront game, and that they'd lose a big piece of their price advantage: sales tax. Having storefronts mean that all sales, online and offline, would be charged sales tax in states where those stores existed. Saving that 4-10% figures into their pricing advantage in an enormous way, and storefronts kill it instantly.
But it's far more fun to think about Amazon trying to compete for those customers who need something immediately. It's not insane that Amazon might dive into the storefront crowd (I didn't say it was likely, just not insane). It would certainly be counterintuitive to folks at Amazon, but let's imagine that they're inspired by the success of Apple's play into storefronts.
What would an Amazon store look like? A few ideas:
How else could a great online store, like Amazon, transform the storefront experience for the better? What would you do if you were in charge of creating an Amazon storefront? It's all fantasy-land, but it's the fun kind.
]]>Some went on to argue that from a rational standpoint, Twitter might not make much sense since it doesn’t directly generate ROI, however emotionally it was huge. With Twitter, consumers feel more connected to a brand. Plus, aside from a resource cost, there is no other cost, so why not be on Twitter?
On the other hand, some argued that there IS a tangible ROI. Take Dell for example, who claims that Twitter has helped to bring in $3MM in sales thus far.
As always, however, with good comes bad. In the case of Twitter it’s risk. One negative @reply about your brand and you could be destroyed. Well, maybe not destroyed, but it could certainly sting a little.
The final conclusion was that, regardless of ROI, cost, or risk, the key benefit of Twitter was the consumer-to-company relationships and emotional branding it adds. Consumers want to peak “behind the scenes” and enjoy access to individuals of companies. They want to be able to communicate with that brand whether it’s to give props or complain.
Of course this doesn’t just mean that all brands should hop on Twitter bandwagon. The only way consumers will actually feel that emotional connection via Twitter is if a company uses Twitter correctly. This isn’t always easy, as consumers are becoming more attuned to marketing speak and insincerity. Some examples of good uses of Twitter that the group mentioned:
In the end, all agreed that Twitter is an emotional form of branding. And, there is a place for it in company’s marketing strategy.
What do you think about Twitter and emotional branding? How does your brand utilize Twitter? Let us know in a comment.
Thanks to everyone who made it out to this month’s MSN, hopefully we’ll see you all again (and more) next month!
]]>Autotest is a fantastic way to do TDD/BDD. Here’s a rundown of the benefits from the project homepage:
Like any responsible Ruby citizen, Autotest changes radically every month or so. A few weeks ago, some enterprising developers released autotest-mac (now autotest-fsevent), which monitors code changes via native OS X system events rather than by polling the hard drive, increasing battery and disk life and improving performance. Here’s how get Autotest running on your Mac, current as of this morning:
Install autotest:
gem install ZenTest
Or, if you’ve already got an older version installed:
gem update ZenTest gem cleanup ZenTest
Install autotest-rails:
gem install autotest-rails
Install autotest-fsevent:
gem install autotest-fsevent
Install autotest-growl:
gem install autotest-growl
Make a ~/.autotest file, with the following:
require "autotest/growl" require "autotest/fsevent"
Run autotest in your app root.
Autotest is a fundamental part of my development workflow, and well worth the occasional setup headache; give it a shot and I think you’ll agree. These instructions should be enough to get you up and running, unless you’re reading this more than three weeks after it was published, in which case all. bets. are. off.
]]>Some (like the BBC’s article, “Twitter Hype Punctured by Study”) have suggested that this study means Twitter lacks retention value and that it’s not actually catching on with the masses. I’d argue the exact opposite. Rather, it shows that Twitter is moving into an untapped niche as an information aggregator, which has big implications for companies’ social media marketing strategies.
It’s a good thing that people aren’t using Twitter like Facebook. (HBS estimates that the top 10% of other social media sites’ members generate 30% of the sites’ content.) Although the original idea behind Twitter may have been Facebook-esque (updating people on what you’re doing and staying in touch with friends), the site’s purpose has morphed—which I think will keep it sustainable in the long run.
The Iran Election has shown this direction that Twitter is morphing: it’s where people go for up-to-the second breaking information and opinion. People are less concerned about speaking and more about listening—listening to thought leaders, celebrities, and people “on the ground.” For this type of information, no one else can compete: the news is too delayed, blogs are often too elaborate to update from a phone, most search isn’t in real time, and Facebook allows users access only to their Friends’ updates. The ability to search for breaking content sets Twitter apart.
What does this evolution in Twitter mean for companies looking to market through social media? First, it means Twitter’s not going away. Twitter has grown from 1.7 million unique visitors in May 2008 to over 19.7 million in May 2009, which signals that there’s something appealing to users aside from the media hype, even if users aren’t tweeting themselves. Therefore, companies looking to enter the social media sphere can’t overlook Twitter as a passing fad.
Second, it means companies should focus less on going through layers of bureaucracy to create the perfect message, and more on distributing the message as quickly as possible to an audience craving up-to-the second updates. Third, I think it means that companies should worry less about using Twitter to have conversations with a small vocal minority, and more about creating relevant, timely, and interesting messages which make the passive majority want to follow the company.
Twitter is finally falling into its niche and gaining its own identity. Companies who recognize and adapt early to users’ trends will give themselves the best chance to capture coveted social media mindshare.
But while this approach has indeed helped us make products on the web that can appeal to a mass audience, it is starting to show its limitations. After a few months (weeks?) of using a simplicity-centric product like Basecamp, you start to run up against its limitations: it may facilitate the way that the creators work best, but you're not quite like the creators. Maybe you've outgrown the simple feature set and need more for your modestly-growing needs. Maybe you no longer have a few months' worth of content in the system, but now have years of content, and managing it all has become a bear. Simplicity is beginning to fail.
Part of the problem is that simplicity is the solution to a problem poorly-identified. Life is complex, and tools to conquer life's complexity need to instead embrace it, rather than ignore it.
A former student of philosophy, I can't get away from a conversation about simplicity without bringing up Occam's Razor. This principle, commonly referred to as the *simplicity principle*, is core to all logical and philosophical argument, and really ends up being at the core of the contemporary drive for simplicity in design.
The idea is that the best solution to any problem is that which has the fewest assumptions or factors, eliminating anything from the equation that doesn't matter enough to impact the outcome.
This sounds pretty straight-forward, and is a great tool for evaluating your own progress toward the solution to a problem. However, the devil, as always, is in the details. It's easy to eliminate a factor -- it's much more difficult to know that it doesn't matter enough.
Some concepts just aren't simple, no matter how they're framed. A few weeks ago, I was talking with Ali about her work on a guerilla redesign of the Supreme Court's website. As we were talking, we kept coming back to the fact that stakeholders involved were chasing after simplicity, and Supreme Court decisions aren't simple. A legal decision at that level can't be boiled down to a score like a baseball game, and even the most succinct summaries require a bit of background.
Complexity isn't confined solely to the fields of law and medicine. In fact, common, everyday tools often need explanation and clarification to be adequately understood. Other times, many simple tools need to come together in a way that creates complexity.
By trying to simplify the inherently complex, you're likely to run into one of two outcomes:
In the end, Ali's redesign was an overall success, but there are specific parts of the interface that are over-simplified and actually end up being misleading rather than helpful. They're small factors, but they detract and distract from the otherwise-overwhelming success of the project.
Instead of valuing simplicity, consider valuing focus. If your design focuses on specific goals or tasks, like being able to manage domain names, you're able to embrace simplicity or complexity as it makes sense.
You may make the process for renewing a domain name incredibly simple, where the process for managing DNS entries could vary in complexity depending on the task -- adding a subdomain may be simple at first, but complexity could be allowed for changing a subdomain's TTL. If you've ever had to transition a website from one server to another, you know how important the ability to manage a TTL can be to a smooth transition, but many domain name providers don't provide an interface to make that adjustment, seemingly with the goal of simplifying the interface.
Focus allows you to create features for more advanced or experienced users, who often allow and in fact desire complexity. Focus also allows you to ensure that new users are able to complete tasks as easily as possible, without oversimplifying the problem. Focus provides liberation from the bonds of simplicity while still providing the constraint that aids successful design.
When you come across complexity within the scope of a focused design, the question moves to how that complexity can best be managed. While this is the topic for at least a book or two, there are a few strategies worth sharing that can help move a design toward success.
All of this management of complexity is assuredly complex in itself, but it's not something we can eliminate from the problem with Occam's razor. It's part of our jobs as designers and architects to tackle the hard work along with the easy work, and that means solving the whole problem.
Hopefully the next five years will be those where web designers learn to focus, rather than simplify. If so, we'll be making new tools that not only work well, but help us conquer some of life's more complicated problems.
]]>
Last Friday, some fellow “Vigeteers” and I made our way down the street to the State Theater for this year’s edition of BlogPotomac, a one-day social media marketing event. Below are a couple of key takeaways from the day’s discussions.
1. Have a Digital Hub
Ford Motor Company’s Social Media Lead Scott Monty spoke on crisis communication and the importance of an organization having a digital hub. A digital hub is an official web site, microsite, or blog that serves as an anchor to link back to as your organization engages in social media. Scott offered The Ford Story as an example and reinforced Shel Holtz’s belief that blogs are not dying. Blogs will continue to be used for what they are good at; offering a means of rapid response in an authoritative and archived fashion (i.e., a type of digital hub). Shel pointed to Southwest Airlines’ Nuts About Southwest blog in his talk.
2. Respond, Respond, Respond!
Both Scott Monty and Network Solutions’ Social Media Swami Shashi Bellamkonda discussed their use of social media in crisis communications. Their message was simple: respond! Responding to negative comments or misinformation is the single most effective way to promote transparency and, therefore, trust. Both speakers agreed that the last thing an organization should do in crisis is to go quiet. A response as simple as, “we’re looking into it” can go a long way. Both shared instances where a “we’re looking into it” response sparked others to comment on their organization's behalf. What if we can’t respond due to possible litigation? Shashi recommends responding by saying you can’t respond. How quickly should one respond to a crisis? Shashi tries to respond in 30 minutes or less, noting that a response changes the tone of comments from yelling to a conversation.
Similarly, Scott’s advice for assessing and responding to a crisis included:
For other impressions and recaps of the event search Twitter for the hashtag #blogpotomac.
Thanks to Geoff Livingston and Jen McClure for hosting the event! Sadly, the third and final BlogPotomac will be October 23, 2009. Stay tuned to the www.blogpotomac.com for details.
