With mobile smartphone use growing at such an astounding pace, I’m constantly amazed that there are still so many top-tier companies that do not have a dedicated mobile website experience. I believe that this rapid growth seems to be outpacing many  IT and marketing executives’ ability to digest and grasp how mobile is going to drastically affect their business growth – particularly in the consumer space.

With mobile, the year 2012 will be a unique parallel to 1996-97, when many industry titans were caught with their pants down by the speed at which web use grew, and were unable to launch a compelling website faster than their competitors.

Let me throw some facts out there that should cause pause:

• This past quarter, Apple sold 62 million iOS devices – and  over 100,000 more iPhones were sold per day than people born in the world per day. In December, Android activations also outpaced births by around 2:1. Apple had the second most-profitable quarter in the history of the US, and was averaging $144,444.44 in profits per day, mostly from the sale of iOS devices.
• During this past year’s holiday season, purchases made via a mobile device grew by 172.9%, and 7% of online purchases were made via an iPad – a device that didn’t exist 18 months earlier.
• YouTube says that the switch from primarily PC use to mobile use for online video will definitely happen by 2013, and may happen sooner.
• app.ft.com, the iOS only version of the Financial Times, has over 1 million registered users, who account for 20% of all page views and 15% of new digital subscriptions. Those who register their device are 2.5 times more likely to subscribe, and 45% of users add the app to their home screen.
• The Weather Channel had 1.3 billion mobile page views in October 2011, compared to 1.1 billion desktop views. They predict that mobile use will outpace TV in less than two years.
• And Facebook says that 350 million of their 800 million monthly active users are checking their statuses via a mobile device. CTO Bret Taylor says, “A few years from now, most every single person at Facebook who works there is going to be working on mobile almost exclusively.” and “Companies really need to redefine themselves in this world of devices rather than browsers on people’s laptops.”

A great transition is happening on the web right now, as our devices redefine how we consume and use information. Due to location and context capabilities, mobile users will want different things from your site, so simply making a mobile copy of your desktop website may not be enough.

Luckily, the tools and knowledge are available to help your company become mobile-friendly. Building a mobile-ready site doesn’t have to be expensive and cumbersome, but it does need to be a priority… probably your top priority.

Related: Check out our What is Responsive Design? series for strategies to build a site that looks great on all devices.

Our client’s requirements were as follows:

1. Create two “site regions” (languages): North America and Europe
2. Provide the ability to translate a node for each region
3. Automatically detect location of user by IP address and redirect them to either the North American or European translated site based on a mapped list of countries

In this post, I address client requirements #1 and #2 listed above, with details on #3 coming in a subsequent post down the road.

Step 1: Create Two Predefined Regions—North America and Europe

In order to create “Regions,” the “Locale” module—part of Drupal core—must be enabled. Technically, the “Locale” module enables the ability to add “Languages,” which I used as “Regions.”

In the configuration of the “Locale” module (/admin/config/regional/language), I was able to change the default name of the “English” language to “North America” as well as add an “English, British” language that I renamed to “Europe.”

Part of the client’s requirements were that the language be determined via a path prefix (e.g., http://example.com/en/, or http://example.com/en-gb/), accomplished by selecting the “Determine the language from the URL (Path prefix or domain)” check box in the “Detection and Selection” tab of the “Locale” configuration page.

Step 2: Content Translation

After reading, Drupal 7′s new multilingual systems compilation, I was certain the Content Translation module (d7 core) was all that was needed to serve region- (language) specific content. After enabling and configuring the “Content Translation” module as well as editing the “Multilingual” support section of my content types so that they were translatable, it appeared that everything was working as desired. I was now able to create a node, assign a node to a particular language and create the corresponding translation.

To test the translations, I enabled the “Language Switcher” block that is automatically created by the “Content Translation” module. Now while viewing a node, located at http://example.com/my-node, if I clicked “Europe” on the “Language Switcher” block, the URL changed to http://example.com/en-gb/my-node and the Europe translation is displayed. WINNING, right?! Just as I was ready to mark my Bugzilla ticket as completed, I realized a show stopper. Menus…

Since “Content Translation” actually creates an entirely new node for each translation, there was no way for me to have one menu item that would link to the corresponding node translation depending on which region is selected. The test node I created previously had a menu item titled “My Node,” assigned to the North America language translation, and I gave both translations the same exact path alias—my-node—assuming the Drupal menu system would be smart enough to handle the node translations, but the results were not as I desired.

When on a page in my Drupal site without a language path prefix (e.g., http://example.com, and I click my menu item, “My Node”), I am taken to the nodes page, http://example.com/my-node. Now when I click the Europe link in my “Language Switcher” block, I am taken to http://example.com/en-gb/my-node. Here was my issue—now when I click on my “My Node” menu item, it takes me to http://example.com/en-gb/node/1 (1 being the node ID of my North American translation). I was expecting to be taken to the same page I was currently on, or at the least taken to the North America translation for the node using the correct path: http://example.com/my-node.

Up until now, I had been fairly calm and the process had been, for lack of a better word, painless. But the pain had just started. I began to research/search/scour the web in hopes of finding a similar situation and solution. Unfortunately, the only “solution” I found was to use the “i18n Menu Translation” module, which essentially requires you to duplicate EVERY menu item, child-item, etc… Now, I’m furious. Really, Drupal? While going the “Menu Translation” route may work for a site with a simple one-level main menu, the menu in this project was about three levels deep, not to mention that on some of the Panel pages, we were displaying menu segments that were path specific. Just as I was about to throw my hands in the air and surrender/purchase Joomla stock/apply for a job at In-N-Out Burger, I stumbled across a magical module called Entity Translation!

Entity Translation FTW!

The difference between the “Entity Translation” module and d7′s core “Content Translation” module is that the former does NOT create additional nodes for translations, it translates on a field-able entity level. Now, this made much more sense to me. I would have one node with translated fields as opposed to two separate nodes with the “Content Translation” module.

It was during this process that I also discovered the “Path Translation” module, part of the i18n collection.

Winning Combo: Entity Translation + i18n Path Translation

After countless hours, I had finally found my winning solution. With both the “Entity Translation” and “i18n Path Translation” modules enabled, I changed the “Multilingual” support section of my content type to “Enabled with field translation.” I cleared my Drupal cache, refresh, and… boom! A single menu item per node regardless of how many translations it has. Translated content is displayed based on the URL’s path prefix, and correct path aliases are used. Success, I can mark my Bugzilla ticket as completed, sell my Joomla stock and politely decline my employment offer from In-N-Out!

While I am no expert on creating Multilingual Drupal 7 sites, I don’t understand why/when one would use “Content Translation” over “Entity Translation.” The whole concept of translating on an entity level rather than a node level just made more sense to me. I cannot see any benefit of creating an entirely new node just for a translation.

I hope somebody finds this post useful as I wish it existed when I first started on this task. For more on our thoughts about Drupal, check out our Drupal page.

The keyboard and mouse are no longer the predominant input tools, and we have gone from designing for three major desktop browsers to a myriad of devices ranging from touch-based tablets and phones; smartphones with tiny keyboards; video game controllers and television remotes. In the near future, high-resolution tablets and computer displays will be on the market, and this change will require that pixel-based web design be completely rethought.

Over the past two years, our clients have requested sites built for specific devices—a “main” site for desktops, a “mobile” version with a specific design intended for smartphones, and more recently an “iPad” version—which is really a simplified version of their desktop site. As you can imagine, this strategy introduces a lot of management complexity and cost into the web design and content management process.

Fortunately, there is is a solution. The recent adoption of HTML5 and CSS3 by browser makers, in addition to some JavaScript-based fallback methods, have introduced the holy grail of inter-device design compatibility: responsive design.

Responsive Design: One Site Fits All (Devices)

Simply put, responsive design is a flexible, device-independent technique that allows a single site layout to automatically “shift and adapt” to any size of browser window on any device, at any screen resolution.

In other words, your site’s design layout will readjust to best fit the screen on which it is being viewed. This is accomplished by shifting the location of navigation and content on the page, adding or removing content, and increasing or decreasing image and font sizes so the site automatically provides the best layout for any screen.

Responsive design isn’t a single technology; it represents a radically different strategic design approach and development workflow. We believe it to be so beneficial that we are often recommending that many of our clients consider responsive design for their content-managed sites.

These are some of the benefits that responsive design offers:

• Adapts your site to a specific range of devices without needing to create a separate device-specific site, or without having to change your content.
• Works in every browser, with native support from IE 9 (which is now being actively pushed to users by Microsoft), Firefox, Chrome, Safari, and via JavaScript-based fallback support for IE 6, 7 and 8.
• Is a process that is compatible with content management systems.
• It is significantly less expensive to maintain and deploy than developing and maintaining separate device-specific versions of your site (even if it does initially require more planning and work than a simple desktop site).

Now that you know what responsive design is, it’s time to learn how to drive implementation within your organization. After the holidays, I’ll discuss drawbacks, introduce you to the responsive design workflow and introduce a strategy for integrating responsive design into your existing sites.

This post will be updated with links to the subsequent articles.

Mobile Payments Accelerate

Wallet? What wallet? I have my phone.

There is no doubt the penetration of smartphones has changed the way we communicate, inform and entertain each other. Mobile devices have also changed the way we shop—helping us locate, evaluate and recommend every kind of product or services imaginable, but we still have to pull out the plastic (yeah, some still carry cash) to transact… Well, that final frontier of the commerce experience is also changing, and fast.

The first step has been the easy one. With the proliferation of mobile browsers, e-commerce purveyors have been releasing mobile-friendly sites to attract customers on the go and help them make the final purchase on their devices. Some firms—like BestBuy—have mobile versions of their sites, while others—such as eBay and Amazon—offer mobile web apps and fully native mobile applications. During the next year, you can expect to see every company that is serious about their e-commerce presence, launch or improve their mobile offering.

The next step, which offers the biggest benefit to most consumers, is mobile payment at retail. Whether shopping at a large retailer, a boutique, the farmers’ market or dining at your favorite restaurant, the POS terminal is becoming your phone. While mobile payments at retail have experienced slower adoption in the US, we expect to see dramatic growth in the coming year. In fact, it has already begun.

• The major players in the both the tech and banking industries have been fast at work to create systems that allow consumers to use their phones for payments. PayPal and Google (in conjunction with CitiCards and MasterCard) are offering services today; and we can expect American Express, VISA and others to release new mobile payment offerings soon.
• Less than a year after Starbucks launched an app that allows customer to pay with their phone, the company had hosted 26 million mobile transactions on iOS, BlackBerry and Android.
• During the recent Black Friday annual shopping bonanza, PayPal announced a 516% increase in mobile payments.
• GSI Commerce, a company that manages the online sales and fulfillment for many retailers, announced an increase of 254%.
• Gartner forecasted a global increase in mobile payment volume of 76% to $86 billion with much of the growth coming from North America.
• Each of the top smartphone developers (sans the one most are waiting on) have smartphones that include Near Field Communications (NFC, a wireless technology that provides data transfer between devices in close proximity such as less that 10 centimeters).

Contextual Services Find Their Way

Behavioral tracking, targeted marketing and more… oh joy!

With the proliferation of mobile Internet-enabled devices, we’ve become accustomed to instant access to information no matter where we are. The problem is that we often have to proactively search for this information.

Enter Contextual Services—the ability for your mobile device to be “aware” of the context around you and behave differently as your environment changes. In the next year, we believe it will become commonplace for your device to proactively change settings and notify you of relevant information based on your location and needs. For example,

• If you’re near an electronics store, you’ll automatically get coupons for the HDTV you were researching last night.
• You’ll be able to transfer information between your computer screen to your tablet, simply by placing the devices in proximity to each other and gesturing.
• As you walk into the cleverly named conference room, your phone will automatically silence itself and pull up the online meeting information from your calendar.

The mobile device is one of the few electronics that is typically a single-owner object. Therefore, as your mobile device becomes more integrated in your daily routine, the more personally relevant contextual results you’ll receive. We expect to see personally relevant contextual services emerge in a convergence between mobile advertising, advanced artificial intelligence (such as Apple’s Siri), gaming, shopping, directory assistance and opportunity discovery.

Contextual services are already blazing trails in the marketplace. Gartner estimates contextual awareness will be a “$12 billion market by 2012“. Startups like Urban Airship and hipui are building advanced tools to help your business take advantage of contextual awareness. Apple already uses contextual awareness in their stores to help associates spot customers in need of assistance. Nokia is experimenting with highly personalized contextual awareness via Nokia Situations.

Mobile Website As Apps

The lines between mobile websites and apps are blurring.

Mobile apps are now a high priority for our clients, which is no surprise given that Morgan Stanley expects mobile Internet usage to surpass desktop Internet usage by 2014. Deploying a best in class mobile solution used to mean writing separate native applications for iOS, Android, BlackBerry, Windows Phone 7 and others. But in the past year, that’s all changed.

Recent advances in JavaScript libraries—such as jQuery Mobile and Sencha Touch—combined with near-universal support for HTML5 and CSS3 make cross-platform, best-in-class web applications a viable option over traditional native applications. We are counseling our clients to keep a keen eye on web apps because they provide several key advantages:

• Web apps are often significantly less costly to develop and maintain
• Users can place a web app icon on the home screen, and the app will behave similarly to a native app
• Unlike native apps, separate web apps do not need to be developed for individual platforms
• There are no app store or marketplace restrictions on content or functionality
• The burden to install and manually upgrade the app no longer falls on the user

The Financial Times made a bold move this past year and eschewed the native app in favor of a sophisticated web application to deliver their daily news content. Their primary motivation was to avoid Apple’s 30% in-app subscription tax, but they also reaped the benefits of lower maintenance costs and instant feature releases. Amazon brought their popular Kindle reading platform to Safari for the iPad with Kindle Cloud Reader, with promises to support more mobile browsers shortly. Google has also put a strong emphasis on mobile web apps for all of their major products, with best in class offerings for Search, Google+, Picassa, Gmail, Google Docs and YouTube.

Certainly, there are still cases where a native app might make more sense than a web app, particularly in areas where rich business logic, advanced graphics or visualization is required. But for most information consumption scenarios, we predict that web apps will become the de facto choice for deployment.

From all of us at ThoughtMatrix, we wish you a very Happy Holiday and anticipate connecting with you again in the New Year.

ThoughtMatrix is joining Silicon Valley tech leaders in opposing this legislation because provisions in these two bills will irrevocably damage the technically and civilly free internet as we know it, and potentially wipe out the fastest growing Silicon Valley job creators.

Without digging too deep, SOPA and PROTECT-IP sound like good ideas. Most people understand that online piracy should be discouraged because it may detrimentally impact the profit margin of content creators. But these ill-conceived bills take the implementation, enforcement and penalties into dangerous (and technically unfeasible) territories:

• The bill would require the same DNS-blocking methods used in China and Iran. Corporations would be given the ability to block entire domains (not just user accounts) that are “capable of” or “seem to encourage” copyright infringement. So if a user uploads a video of themselves lip syncing a copyrighted song to YouTube, the entire YouTube.com domain could be taken offline.
• Ordinary users could face felony charges for “streaming” a copyrighted song. The penalty is a 5 year sentence. As one tweet put it, “Under SOPA, you could get 5 years for uploading a Michael Jackson song, one year more than the doctor who killed him.”
• The integrity and technical reliability of the worldwide DNS system would be jeopardized, since the U.S. DNS servers would have different records than their foreign counterparts.
• Several provisions in the bills would stifle the innovations that Silicon Valley companies have become known for. Millions of tech jobs would be at risk, and the United States would lose its place as the leader in information technology innovation.
• These bills have a high potential of becoming law, since they have significant co-sponsor support on both sides of the isle. The PROTECT-IP Act has 21 Democrats, 16 Republicans and 1 independent. SOPA has 7 Democrats and 16 Republicans co-sponsoring.

SOPA and PROTECT-IP are bills that industry lobbyists crafted. The entertainment industry has spent over $91 million on this issue, and they outspend Silicon Valley lobbying efforts by about 6 to 1. U.S Legislators have stacked the deck against the opposition by refusing requests from technically knowledgable industry players to testify against the bills. Even though the entertainment industry’s experts admit they are not qualified to speak on the technical aspects of the legislation, they insisted that their bills would not create any issues with the worldwide DNS system.

It’s time to act.

SOPA and PROTECT-IP will only be defeated if our Congress sees a groundswell of opposition from their constituents. It only takes a few minutes to take action:

• Visit American Censorship Day and learn more about how to fight SOPA and PROTECT-IP.
• Tumblr has created an easy means to contact your House Representatives about this bill
• Read the SOPA bill (PDF) for yourelf.

For more detailed information on the forces driving rapid change in the UX Design field, watch the “What’s Next for UX” webinar that illustrates new approaches and presents practical methods to help design teams stay ahead of these trends. Watch the webinar now >

Arrested Development?

The standard design process used by most agencies—often referred to as the “waterfall process”— has five familiar phases: Discovery, Design, Implementation, Testing and Launch. Each phase typically consists of separate teams held together by a project manager who serves as the primary link between the phases and teams. Each phase is focused on a set of deliverables and comes to a conclusion once those deliverables (e.g., competitive analysis, creative brief, coded templates, etc.) have been completed and approved by the client. The process relies on the deliverables to ultimately provide more definition for the final product. If everything moves along smoothly, the project launches with the successful completion of the goals stated at the outset. However, while the waterfall process has been embraced thoroughly by our industry and clients, it has many shortcomings that make it ripe for failure.

The waterfall process was developed as a defensive measure to ensure a clear set of milestones and deliverables in order to keep close track of how a project is progressing. While the focus helps teams ensure the delivery of a finished product, it limits the opportunity for open exploration by not being adaptable to change. Every project proceeds with a set of assumptions that are very often upended during design exploration, thereby requiring a completely different approach. With the waterfall process, change is met with resistance because it is simply not built into the plan. Furthermore, assumptions may never be put to the test because frequent assessments of the work are not a part of the overall process.

In addition, the discrete stages inherent with the waterfall process often lead to communication challenges. For example, typically the design phase will only include the project manager and design team. As they work to provide the functional and aesthetic definition, many decisions that require input from the development team is often times left until the end of the design phase and the beginning of the implementation phase. This silo effect tends to lead to a higher potential of risk with poor technical decisions made during the design phase that require changes during implementation.

A Better Way

The approach used at ThoughtMatrix—Lean UX—seeks to fix the disjointed waterfall process by creating a unified team focused on the finished product from the get go. Business owners, project managers, developers, designers, content strategists and others work together in a small, dedicated team. The team compresses the research, design, development, testing and validation process into two- to four-week tight-looped cycles similar to Agile development. After each cycle, assumptions, design and code are validated with users, and the accepted components remain while unresolved features/functionality are reworked in the next cycle. All along, the focus is on the final product so every contribution by each team member impacts the final product, not just a single phase of the project. The result is a process that’s always focused on the final product while at the same time open to unbridled exploration and constant reflection that vastly improves the end result.

Lean UX Illustrated
Borrowing heavily from the Agile Development Process, Lean UX was first coined by entrepreneur and author Eric Reis, who in the aftermath of the Internet Bubble sought to find a way to bring ideas to end users more quickly to validate new business ideas before scarce capital was wasted. Cycles typically last between 2-4 weeks and involve all aspects of the design process from research, design, development and testing to validate each feature before moving on to the next.

Mobile First

The latest and greatest technologies and content—such as Flash and video—have turned many websites into incomprehensible digital behemoths. So many different stakeholders are involved in any digital endeavor that it’s no wonder that the voice of the customer is often lost in a sea of navigation and promotional content. That complexity is further compounded when accommodating for new avenues of information consumption—most specifically for smartphones and tablets. Forty percent of mobile consumers over 18 in the U.S. now have smartphones and that number is expected to exceed 50% by the end of 2011*. With that kind of penetration and growth, UX designers need to start thinking about mobile first.

Designing a product for Mobile First requires a great deal of focus. Constrained by limited screen real estate, distracted users, and on-the-go interaction, the mobile first approach forces teams to concentrate on what really matters to users. It’s no longer acceptable to merely place extra content in an overlay or add another item to the navigation to try to retrofit the needs of the mobile user. Mobile limits you to a very small screen space—typically 320 x 480 ppi on a smartphone compared to 1000 x 650 ppi for a typical desktop browser—which is virtually an 80% reduction in screen space. Thus, it is essential to deliver what the visitor wants immediately, or abandonment will be inevitable.

Mobile users are usually on the go, checking their friend’s Facebook status as they cross the street or ordering a latte at Starbucks, browsing sites while riding transit or in-between appointments. Focusing on how to enable mobile users to quickly and easily navigate to the content they need when they need it also helps to solve challenges that come with the wide-open spaces of the desktop browser. Sometimes less is more when it comes to helping users quickly and easily find content they care about.

Focus
Walgreens.com has more than four choices to get to the pharmacy adding a lot of clutter to a confusing homepage design with many competing elements. The iPhone app presents nine easy to scan options even providing users the ability to customize the apps home screen with the choices they use most.

Big Forces Driving Change

Embracing the tenants of Lean UX and encouraging a Mobile First design approach even when mobile development is not part of the project have a significant impact on the quality of the work being done at ThoughtMatrix.

What’s Next for UX Webinar

For more detailed information on the forces driving rapid change in the UX Design field, watch the “What’s Next for UX” webinar that illustrates new approaches and presents practical methods to help design teams stay ahead of these trends. Watch the webinar now >

1. Consider the user’s situation

It’s important to remember that while mobile bandwidth has improved immensely over the last few years, there are still many areas where coverage is not ideal. For this reason it’s critical to present the most important content first in order to better accommodate your user’s situation. For example, a restaurant would likely want to include its contact information and hours prominently on the home page since mobile customers accessing their site are likely seeking to find directions to the restaurant or trying to make, cancel or change a reservation. By creating user scenarios—as opposed to the more traditional user personas—you can pinpoint these situational differences that are critical to your mobile content strategy.

2. Consider the user’s motivations

People tend to access the Internet from their mobile phone for different reasons than they would if they were on a laptop or desktop. For example, a user in a sporting goods store may visit a bicycle manufacturer’s site to determine which bike model in their consideration set best fits their needs. In this case, they’re looking to find very specific, comparative information quickly, so the best content choice may be a comparison chart instead of long flowing paragraphs about the lifestyle virtues of riding a bike.

Another example is a user who is at a Target store and wants to see if there are any available coupons for the Lego play set she is thinking of buying. In this example, having a link to “Offers” on the highest level of the mobile site will connect customers to real benefits faster. Again, these are contextual details that can be uncovered through the user scenario development process.

3. Consider the usability

From the amount of email signatures out there that say something like, “Sent from my iPhone, please excuse typos,” it’s clear that typing on a mobile device can be challenging. That’s why it is important to present content that is easy to access and use. Whenever possible, provide selectable lists instead of making the user type something. You can utilize your analytics to present the most popular content first.

For example, if you have a pregnancy support site and your analytics indicate that the majority of mobile users are visiting the “Am I in labor?” page, you may want to present that page from a selectable list of popular topics. My guess is that most women would be grateful to not have to type while in the midst of painful contractions.

Use Qualitative & Quantitative Data

Creating a mobile content strategy requires a combination of qualitative research and quantitative analytics that, when combined, paint a more specific picture of your user’s motivations, desires and needs. By fielding user polls and reviewing your data, you can better map content to your users’ goals to optimal create mobile experiences that truly deliver.

Not too long ago I was consistently posting updates using TweetDeck (and HootSuite on my iPhone and iPad), and it only took me about 15 minutes per day. My 2-3 daily posts seemingly kept me top of mind with my network, and it was paying off. I maintained dialogue with many existing contacts as well as established new connections. I had a good system going, so what happened? Well, at some point I just got too busy. Then it didn’t take long before my scheduled morning and evening tweets and posts fell by the wayside, leaving only ad hoc status updates to my Facebook profile so that my family knew I was still breathing. Sound familiar?

The good news is signing up for Google+ gave me pause to reflect on my old reliable TweetDeck system. So the other day, I took a few minutes to write a short post alerting my surf buddies that the O’Neill Cold Water Classic competition was in Santa Cruz and should not be missed. Five minutes and a few posts and tweets later, I felt like I had made progress immediately! Love that instant gratification.

Experts agree that it takes a minimum of 21 days to change a behavior, whether it’s adopting a new exercise regime, diet, quitting smoking­—you get the idea. It’s all about consistency. I’m confident that this theory will also apply to my goal of reestablishing my social networking routine to increase its effectiveness.

Join me by creating your own 21-day challenge program! And follow, like , friend, and connect with me to see how I’m doing.

Next blog in 21 days with the results!

We recently uncovered an excellent example of the immature state of Drupal 7 versus its well-established predecessor Drupal 6. We noticed early on in a recent project that the underlying data structure for content had changed in Drupal—there is now a component of the content-element data object that stores a Language ID for each value, which didn’t exist in D6 (granted, it’s always set to “undefined”, but it is there). This means that, in theory, individual content elements can have different language values, even in a single node (e.g. /node/123 can be displayed with English or French content).

In previous versions of Drupal, including Drupal 6, each language-version of a page was really a separate node (e.g. /node/123 in English, but /node/234 in French). That approach meant the nodes were only slightly related to each other, which often complicated the design and management of navigation menus, path aliases, taxonomies and other structural elements. In theory at least, Drupal 7 has improved the model by making it more granular and more unified, allowing a single node to be truly multilingual. While that may sound nice, in actual practice, the new data structure can be really frustrating to work with because none of the core Drupal 7 modules take advantage of it. As an example, since there is no user interface, developing a multilingual site in Drupal 7 still requires creating separate nodes for each version of a page. To be fair though, there is a new, and still experimental, D7 module called “Entity Translation” that utilizes this new language-data structure, but that module was just released in early September and it has yet to be truly tested in a real-world environment. Therefore, it’s not prudent to release a live site for a client until the module has been thoroughly exercised. Who knows how many bug fixes and other yet-to-be-written supporting modules will be needed to eventually make this new paradigm compatible with all the core system modules, and practical for use in real-world projects and translation workflows.

Drupal 7 is promising, but it’s not there yet

There are, in fact, several new immature features of Drupal 7 that are either incomplete and/or only partially implemented. In general, the fact that D6 has so many more modules available along with a vast knowledge base, means that in practical terms, Drupal 7 is actually less functional than Drupal 6 for anything other than testing or non-critical applications.

There’s nothing we can point to that the current iteration of Drupal 7 can do that can’t be accomplished in Drupal 6—often better and with a much higher degree of stability and confidence using modules that have been refined and improved over time. Don’t get me wrong, Drupal7 isn’t horrible, it’s good just not as good as D6 yet. So far, we can’t enthusiastically recommend it to our clients. However, we are hopeful that the structural changes will eventually lead to something that greatly improves the model for creating multi-language sites.

Post submitted by Michael Madden, ThoughtMatrix

whose — The possessive form of who.

Examples of whose:

I wonder whose idea it was to put big bowls of candy on the conference table.

Whose CMS is likely to gain the biggest market share?

Jim is the one whose crazy ideas might just make him rich some day.

who’s— Is a contraction of who is or who has.

Examples of who’s as the contraction of who is:

Who’s going to handle the 33,000 pages of content migration?

Tony is the one who’s going to lead the meeting.

Examples of who’s as the contraction of who has:

Who’s eaten all of the candy in the conference room?

Jeremy is the one who’s done the most work on the website.