Thursday, March 20, 2008

Notes by Southwest: Notes from 3/11/08

Notes from sessions attended on 3/11/08 at South by Southwest.

“Content Management System Roundup”

Just the Gist

Comparison between:

George DeMet,

Jeff Eaton,

Tiffany Farriss,

Mike Essl,

Matthew McDermott,
Principal Consultant,
Catapult Systems

View Notes

  • Sharepoint (George DeMet - MS Sharepoint MVP)
    • Full office suite allows for intranet and internet connection
    • “Master page” + “Page layouts”
    • Sharepoint designer
    • Authoring view - DHMTL menus with options (when viewing pages)
    • Workflow process and approvals built into system
    • Branching built in for design variations and future changes (also versioning)
    • Searching is included into the system
    • Thesaurus and relevance ranking
    • XSL + XML compliant
    • “variations” - usually for multilingual sites
    • “My Site” for intranet users
    • Nav + breadcrumb
  • Drupal - Jeff Eaton
    • Built by the people who use it
    • Hobbyists, businesses, volunteers, Belgians
    • Fast Company, many other major companies
    • Blogs, magazine sites, Terminus 1525 (artists community),
    • LifeTime TV
    • Pete Droge - all Flash content,, The Onion
    • End Poverty, Inc. Magazine, U.S. Magazine, DC Comics “Zuda”, Pop Sugar, Interfacultair, Sony Music Box
    • Around 3,000 plugins
    • Theme > Views of Content > Content > Users > Modules and Drupal Core
    • Users all have roles - designed to accommodate a large number of users
    • Blog post - can filter by user
    • Theme layer - generates all xml, html, mobile
    • Can have all mobile pages
    • Default Drupal site is very basic, functionality is added on via customization and plugin installation
    • Great at:
      • user-generated content
      • Many kinds of content
      • Communication
      • Versioned content
    • Other sites:
      • Daughtry (Sony BMG)
      • Artist interaction with community
      • Multiple sites can be run from the same core
      • Sony contributing back to project
  • Expression Engine - Mike Essl
    • “Me and Mr. T” - no custom PHP
    • Archive, error, xhtml, css-compliant
    • All fields on site
    • Invisible NYC
    • Material research - site coded in one day
  • Evolution of CMS choices - Art Institute, Chicago
    • Museum side and school side (2 sides to site)
    • Round 1 (Custom PHP)
      • Dreamweaver + CMS
      • Good: quickly created and running, discrete scope, targeted, simple
      • Bad: Navigation, difficult to extend, support (interim solution - rarely interim)
    • Round 2 (Serena Collage)
      • Nice master page structure
      • Breadcrumbs
      • “Contribution layouts”
      • Good: Master pages, workflow, version control, training contributors, breadcrumbs, links as assets, deployment
      • Bad: Expensive, slow performance, not mac friendly, navigation, training devs, interdepartmental, no support - dynamic, end-of-life product
    • Rounds 3 (Drupal)
      • Indianapolis Museum of Art
      • Drupal - JQuery integration
      • Can customize skin through interface
      • Powerful templating
      • Remote data
      • User management
      • JQuery integration
  • Q+A
    • Drupal - created an install profile to make new installs easier
    • Actions and workflow - control access and approval (built into Sharepoint)

“Creative Collaboration: Building Web Apps Together”

Just the Gist

  • Make sure that developers and designers are talking early in the process
  • It helps for the designer to sit in the same area as the developers
  • Team members need to be multi-talented in today’s environment

Paul Hammond,

Simon Willison

George Oates,
Lead Designer,

Matt Biddulph,

Dave Shea,

View Notes

  • Dopplr
    • About 1 year old, 4 people
    • Ships several times per day
    • Very collaborative
    • “Technical wife and design husband”
    • All active features can be switched on and off in dashboard
    • Live testing = sculpting, not painting
  • Simon Willison
    • Used to work at Lawrence Journal-World
      • Local paper in small town in Kansas
      • 2 devs, 1 designer (css + html engineer), bunch of editorial staff
      • The work at Lawrence Journal-World grew into the Django framework
    • Parallel Workflow
    • Devs design the underlying data model
    • Automated admin interface allows content producers to start entering data
    • Devs building the logic for the customer-facing pages
    • Today...
      • With apps, underlying data is not as consistent
      • Continuing collaboration with a designer is essential right from the start
  • Dave Shea - Mezzoblue
    • Client design work, designer who codes
    • Independent
  • George Oates
    •, over 2.3 million photos
    • Paper and whiteboard
    • Over 20 million photos
    • Core dev team grown from 3 (5) to 16 (40)
    • Supporting cast of over 100 people
    • Still try to release early/often, but is difficult with more people and a larger organization


  • Everyone responds well to seeing a design mockup
  • Collaboration between the roles - don’t leave out
  • Flipside, “skin this”
  • Make sure both are involved early
  • Sit in the same room
  • The top-down stuff can cause a top-down breakdown
  • Prototyping very useful, especially with live data
  • When you build prototypes (in company)
  • Depends on skill-set of team

Job Roles

  • Need to be multi-talented
  • Most productive involve small teams of generalists
  • Shared understanding of produce - voice of product
  • Devs can see weird little use cases, errors, etc
  • Especially important for independent to generalize
  • Larger teams have a harder time making decisions
  • Sometimes there isn’t as much overlap as there should be
  • Process is an antidote for stupid people
  • Shea: Contracts explicitly set out a design process
    • Enforced only if it’s taking too long
  • Humans don’t respond well to anarchy but also revolt against overly pressuring red tape
  • Internationalization can invite more problems
  • Designing for blank slate, zero data, data constraints, are important when designers are working with live data
  • Learning svn is a very good idea

How can devs and designers communicate more effectively?

  • Client-side vs. back-end developers - need to have people that are focused on each
  • Abstractions are a little to tough to talk about in the beginning
  • Agile change management and request systems
  • Quickly make suggestions and rebuttal - smarty for PHP
  • Bugs and design decisions
  • Differences between team structure and personalities
  • The design quality of the prototypes should reflect the level of completion
  • Put a css class on the pieces that are not finished
  • Mentoring is incredibly important
  • Agile really relies on client being present
  • Client-side dev - at least slice up images

“Taking Over the World: the Flickr Way”

Just the Gist

  • Localization can be made less painful, but requires a lot of good planning
  • Community and professional translation methods can be leveraged for community-centered sites
  • The business must also be localized, how will you provide support and allow feedback for other languages?
  • Always use UTF-8 and plan the system for possible future localization (keep internationalization as part of the creation process)

Simon Batistoni,
Flickr/Yahoo! Inc

View Notes

  • Flickr engineering team
    • Launched June 12th, 2007 -the localization took 7 months for 7 countries
    • Emphasis on language over locale (not everyone in the U.S. speaks English, and that's true for every country in the world - every citizen of a country does not necessarily speak in the official language.)
    • Good set of localization tools when you can use it in a wide range
    • Too many words/legacy code
    • UTF-8 was already being used, helped - time zones
  • Hugely passionate community
  • Usually people aren’t as emotionally invested in most sites
  • Flickr-people feel more passionately
  • Other challenge - owned by a big company. The purchase by Yahoo! gives Flickr a lot of resources to work with, but it also comes with more large company issues to deal with.
  • Introduces other strains and constraints
  • Internationalization vs. localization (i18n vs 110n)


  • What you do to make the site ready for localization
  • Make sure to deal with time properly
    • Character data/sets
    • Community data/sets
    • Community interaction - bugs, reports, etc
  • Content classification - different countries have different value systems, especially an important distinction for media. What is okay in the U.S. is not okay in some other countries, and vice versa.
  • Payment systems
  • When is the right time? Doesn’t really matter, but should worry about it from day one.
  • It’s only okay to not internationalize a system unless you’re absolutely sure that it will not be localized (extremely rare)


    • Not just starting, where does it make sense to begin the process?
    • Language-switch
    • Legal review - large or small company - legal landscape in other countries
    • Ex: YouTube in Pakistan (keeps getting shut off)
    • Issues can impact you in a big way
    • Staffing - need very different structure - need to be able to take things like bug reports, and provide customer customer care. If it needs to be translated for product team to respond, how does that happen?
      • All information must get routed tothe right place to provide the right sort of response
    • Flickr did a tour of all the countries that they were localizing for
      • Ex: Found that Korea didn’t like white layout - too much whitespace
      • Have not yet addressed other versions of template for issues such as this
    • Don’t Rush!
    • Focus on building a really good product first
    • Better to do it late than horribly, to enter a market and get a bad reputation is much harder than to launch when ready

Be prepared

  • Make sure you know where all the text strings are
  • Image tags with titles and acts
  • HTML alone is not enough
  • Some people use keys {sentence_replace_confirm}
    • Downside: debugging templates becomes very difficult with so much meaningless data on the page
    • Slows down entire process
  • Trans Jaxxx - the tool Flickr built for text strings uses a similar marker, but is much easier and semantic to view - just adds little tags like <!!>Text for translation</!!>
  • Also work in title tags and iamges
  • Attributed such as
    • <!! esc=”squat”>TEXT</!!> (escape the string)
    • <!! dev=”replace”> (replace the string)
    • <!! note=”not goes here”> (note for the string)
  • Can be working on 5 or 6 things at one time (features)
  • preg_match_all
  • W3C has internationalization system can all be together
    quite complicated

Say no to concatenation, can cause a lot of problems for the system

  • My {$beverage} brings all the {$gendered-people} to the yard
  • More code than there should be
  • <!!>{$username} added you as a contact</!!}

Dates, times, numbers


  • Use UTF-8, always, just do it
  • Matches ASCII characters
  • Most compact byte representation


  • German is awful for line length
  • Must be flexible
  • Fluid too a degree, has to be able to expand a bit (40-50% - but sometimes too much)
  • When you use images with text in them, need to create them each time - drawback, but makes a decision

Taking The Plunge

  • Established growth
    • Growth potential
    • Usage possibility, or growth market
  • Potential headaches
    • Localize somewhere, need support
    • If not, a web site with no way to contact us - highly discouraging to users
    • Content - legal, cultural issues
  • How much money do you have?
  • Have to worry about translation
  • Translation management tools
  • (
  • Trans Jaxxx - internally (Flickr)-built translation tool
  • Text units have red boxes around them (using the tool)
    • QA people can click on to edit the text
  • Community-powered Translation
    • Free, or at least, cheap
    • Broader demand-driven translation
    • Community ownership of content and process
    • Downside: moderation and QA can be difficult
      • Community or professional for review? Can do it either way, but need to choose early. Some sites are using a mix, this is all easier to do if the site already has a solid user base. English-speakers already using the site are often motivated to help localize the site if they have ownership. in it. The biggest successes have so far been community-based sites, which makes sense because there is a source of motivation for “free work” to be provided.
    • Community-only translation does not address the support issue of providing the same level of support to each country if you are only an English-speaking organization.
    • Also doesn’t allow for secret launches (everybody knows you’re doing it)
    • Examples: Live Journal, Xanga, Facebook, Google
      • Facebook dumped in text from Babblefish and then let the community correct the text
  • Professional Translation
    • Banks of translators, all over the world
    • Is expensive
    • Hard to capture right tone, pros don’t usually care about keeping the tone or personality of the site correct, more about volume
  • Deploy - Flickr deploys between 5 and 10 times per day
  • Pre-bake all templates (PHP + Smarty)


  • Get some advice from someone who knows, which probably means someone from the region that you are localizing in
  • Cultural considerations

Foster A Single Community

  • Tear down the barriers where you can
  • Groups - allow translation of groups by users
  • Other help is geographical stuff
  • Visual means where language doesn’t matter - very helpful
  • Want to make localization seem trivial
  • Google makes assumptions based on IP, but that has a lot of drawbacks
  • Even in US, there are plenty of other languages besides US
  • Flickr uses a multi-stage “flitering” to determine what language to display first:
    • Cookies for return visits, preferences on other Yahoo! properties
    • Look at where they came from (Ex: if the traffic came from a French-speaking site, chances are that they speak French)
    • Flickr also use IP location, never heard complaints

Question & Answer

  • Using .fr for anything?
    • No, but the switching is not good right now
  • Combine community and pro translation?
    • Pro as QA - professional translators provide the quality assurance and make sure that each translation is actually saying the correct thing for each text string
    • Community as work - community provides the text translations
    • “Draft and Official” versions of site - “draft” before it goes into review and becomes “official” text
  • How does Flickr handle support issues for localized versions?
    • Have support agency to filter incoming reports
    • Also have employees to do forums
    • It needs a human being behind it, can’t just throw a product out with a language and no one behind it
  • Release Transjaxxx (the custom internal tool that was written by Flickr)?
    • Would like to, but nothing is solid
    • The downside of most translation software is that it tends to be desktop-based


Anonymous John@ Proflowers Coupon said...

Thanks for the post. I had been looking for something related and found your web site in the process.. I will definitely be back for more.

8:23 AM  

Post a Comment

Subscribe to Post Comments [Atom]

<< Home